Bidirectional range dilemma

[bearophile]

Peter Alexander:

> FWIW, it is not a premature optimisation. On a simple benchmark 
> I did, adding .dup to front() increased runtime by 3.5x on DMD 
> with all optimisations.

Yes, around 3X is compatible with my timings.

I think with a generational GC (you can test it in Java), or with 
some kind of arena allocator, that performance loss will decrease 
significantly (but then you need to add a memory allocator 
template argument, that I presume defaults to the normal GC 
allocator).


> I do care about safety, but I also believe that performance is 
> critically important to D's success.

I care a lot for performance (where performance is needed), but I 
care even more for correctness :-) A fast but buggy program is 
often useless and sometimes it's even dangerous.


> Performance on demands is good in theory, but if I'm writing 
> high performance code then I want performance by default, and I 
> don't want to have to fill my code with annotations and special 
> flags/options.

Compare:

foreach (p; permutations(items)) {...

Vs:

foreach (p; permutations!false(items)) {...

Or even:

foreach (p; permutations!0(items)) {...

Or even:

alias fastPermutations = permutations!false;
foreach (p; fastPermutations(items)) {...



> I think we need a D mission statement that we can refer to, to 
> settle these disputes. How much performance loss is acceptable 
> in the name of safety by default?

I don't think a "mission statement" is enough to settle all such 
questions, in life there is too much variety. You have to decide 
on specific cases, on the base of few general rules, like the D 
Zen rule I have written in the precedent answer.

Bye,
bearophile