Micro performance tweaking in your C or C++ code is not generally
recommended. The gains are almost never worth the trouble. I always
micro performance tune many aspects of code myself as a matter of habit
and it takes me no extra time. But that doesn't mean I suggest you do
the same.
lab@xxxxxxxxxxxxx wrote:
- Avoid i++, use ++i and so on.
Good style decision, but it rarely affects performance. The optimizer
sorts out a lot of cases where a simplistic view of the required
operations might make it seem that ++i would be better than i++.
today i'm investigating this:
int i;
for(i = 0;....);
As a matter of style, I give variables minimum scope. In your trivial
example, I'm sure the scope of i doesn't matter to the reader of the
code nor to the optimizer.
When the scope does matter to the optimizer (better code could be
generated if the scope were narrower) the optimizer often figures out
that the scope could be narrower than what you specified and does the
narrow scope based optimization even if you didn't limit the scope.
Rarely, the optimizer can't deduce the narrower scope and a narrower
scope produces better code, so manually narrowing the scope may improve
performance.
More often, the maintenance programmer can't deduce the narrower scope
so the fact that you didn't manually narrow the scope makes some future
bug fix or enhancement much harder than it should have been.
I understand you weren't directly testing a scope narrowing construct.
An extra set of braces would equally well narrow the scope whether the
declaration is inside or outside the for(;;). But the scope is the only
aspect of that syntax difference that affects performance. Otherwise it
is just style. I find the style of the declaration inside the for(;;)
better at communicating your intent to the maintenance programmer.
But as long as you are trying to micro optimize that common code, let me
suggest a better style change.
for (unsigned i=0; ...)
Don't make an index variable signed unless it needs to be signed. Small
positive numbers are stored with equal correctness by int or unsigned.
But in x86_64 architecture, unsigned will often give better performance
(never in any trivial test cases but often in actual moderately
complicated code). Even though you are using 32 bit x86 now, there is
no cost to code as if your code would be ported to x86_64 later.
