Re: Habitual optimization
Martin Eisenberg wrote:
James Kanze wrote:
Steven T. Hatton wrote:
My question is whether any clock cycles might be saved by
moving some of the arithmetic out of the loops? For example,
would anything be gained by defining:
const int dTick((rect.width() - 1)/settings.numXTicks);
and then writing:
int x = rect.left() + i * dTick;?
Or even `int x(rect.left());' outside the loop, and `x+=dTick';
inside the loop?
It might. The results might also end up running slower
(although it's not too likely). This is the sort of
optimization compilers are very good at, however, so I wouldn't
worry about it in general. More importantly, any modifications
to do it this way later are local, so acting on it before the
profiler says you have to is simply stupid.
Compare the version Steven proposed last to the original:
get distance from voodoo
get starting point
repeat {
plant object here
advance position
}
repeat {
get point from voodoo
put object there
}
Where "voodoo" means something too long to take in with a sideways
glance if one hadn't written it many times before. I find it worth
pointing out that whether a person reads the former rendition as
micro-optimization or as the "natural" way to cast what's going on
depends on personal mode of thinking -- one is more processual, the
other more structural. Neither way is necessarily smarter.
That's a very good point. Choosing one form or the other is, in
many cases, a form of documentation, stating how you were
thinking about the problem, and how it was analysed to prove
correctness. As Dave Harris has pointed out, in many cases,
particularly when floating point arithmetic is involved, the two
forms are not guaranteed to give the same results; you obviously
want to use the form that has been validated to give correct
results. Regardless of which it is.
My comment should be restricted to the idea of not changing the
original form (whichever it was) for presumed performance
reasons, unless actual measures show it to be necessary.
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]