Efficient idiom for fastest code

[Nicholas Wilson]

On Wednesday, 23 May 2018 at 03:12:52 UTC, IntegratedDimensions 
wrote:
> I knew someone was going to say that and I forgot to say DON'T!
>
> Saying to profile when I clearly said these ARE cases where 
> they are slow is just moronic. Please don't use default answers 
> to arguments.
>
> This was a general question about cases on how to attack a 
> problem WHEN profiling says I need to optimize. Your SO 101 
> answer sucks! Sorry!
>
> To prove to you that your answer is invalid:
>
> I profile my code, it says that it is very slow and shows that 
> it is do to the decision checking... I then I have to come here 
> and write up a post trying to explain how to solve the problem. 
> I then get a post telling me I should profile. I then respond I 
> did profile and that this is my problem. A lot of wasted energy 
> when it is better to know a general attack strategy. Yes, some 
> of us can judge if code is needed to be optimized before 
> profiling. It is not difficult. Giving a generic answer that 
> always does not apply and is obvious to anyone trying to do 
> optimization is not helpful. Everyone today pretty must does 
> not even optimize code anymore... this isn't 1979. It's not ok 
> to keep repeating the same mantra. I guess we should turn this 
> in to a meme?
>
> The reason I'm getting on to you is that the "profile before 
> optimization" sounds a bit grade school, specially since I 
> wasn't talking anything about profiling but a general 
> programming pattern speed up code, which is always valid but 
> not always useful(and hence that is when profiling comes in).

I'm going to ignore the tone of your response, but I am going to 
say that responding like that isn't going to get you very far. 
Don't expect others to do likewise.

Assuming that your decision function is indeed the bottleneck, 
you'll see I did actually provide some hints as to how to 
optimise the case where decision is pure. even if you can't 
convince the compiler to inline and expression combine, as in the 
case for the other answer, you can memoize it (look in 
std.functional).

One of the great things about D is that you can force lots of 
computation to happen at compile time, so in the case where 
decision is impure, factoring it into pure and impure parts and 
`enum x = pureFunc(args);`ing the part that can be can make a 
large difference if you can't convince the optimiser to do it for 
you.

If you still can't do that consider Jitting it  
(https://github.com/ldc-developers/druntime/blob/e3bfc5fb780967f1b6807039ff00b2ccaf4b03d9/src/ldc/attributes.d#L78 ) with `-enable-dynamic-compile` or running the loop in parallel with std.parallelism.