[haiku-appserver] Re: [Haiku-commits] r14599 - haiku/trunk/src/servers/app
- From: Adi Oanca <adioanca@xxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Tue, 01 Nov 2005 20:38:19 +0200
Hi Ingo,
Ingo Weinhold wrote:
On 2005-11-01 at 00:02:58 [+0100], Adi Oanca wrote:
Ingo Weinhold wrote:
On 2005-10-31 at 21:50:20 [+0100], Adi Oanca wrote:
[...]
To avoid a few CPU cycles please pull out local declarations from
loops.
Please don't do something like this; keeping variables as local as
possible
increases the readability. Furthermore trust the compiler. Don't try to
trick
it -- it's your friend. Extending the scope of a variable may cause a
bigger
stack footprint and may even make your code slower, since the compiler has
less knowledge it can apply.
Umm... I don't think so. At least my tests and the books I read point
this as a very simple method of optimizing code.
Regarding books about this kind of optimization, one can usually throw them
away when the next compiler version is released.
Maybe. It's good to know such things anyway. :-)
Regarding tests, I couldn't
help it and compiled these two (nonsense) functions:
static void
test1(const char *longString)
{
for (int i = 0; i < 1000; i++) {
const char *str = longString + i;
printf("pos: %d\n", str - longString);
}
}
static void
test1(const char *longString)
{
const char *str;
for (int i = 0; i < 1000; i++) {
str = longString + i;
printf("pos: %d\n", str - longString);
}
}
Compiling without optimization results in different assembler code. Just as
suspected. Unlike you suggest, there is no more overhead involved in the
first version.
No stack pointer addition and subtraction for every iteration?
On x86 local variables are referenced relative to the stack frame pointer
(ebp). Declaring a local variable does not result in actual code, it only
causes the compiler to reserve space for the variable while compiling. In the
first version, the compiler reserves the four bytes at -4(epb) for i and the
four bytes at -8(ebp) for str. In the second version things are just
reversed. No effect on performance.
Hmmm... GCC is smart? :-)
Are you sure not other instruction is executed in the first test?
If not, OK - what to thank you for clarifying this to me.
(BTW, the tests I was talking about - I confused something - was a test
I posted to this list AFAIR, about calling methods from 'for' instead of
direct access)
(readability is down with 5% - not even noticeable)
Do that twenty times and you have -100%. ;-)
OK. :-)
Seriously, readability is paramount especially in an open source project,
where the original author might not maintain the code forever.
Correct!
Thanks,
Adi.
Other related posts:
