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.
