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
