* Gernot Frisch:
Sorry, I don't know how to express my problem.
for(int i=0; i<16; ++i)
{
float data={i, 1,3, i+1,3,4};
do_something(data);
}
is there any way - or must I be concerned - to not re-allocate the
'data' on the stack for every loop?
Using gcc 3.4.5 (if that matters)
Generally this would seem to be a non-problem: memory involved is just a
handful of bytes, execution time a handful of billionth's of second: you
can't possibly blink that fast...
But let's say that by /measuring/ you have found the above to be the big
bottleneck of your app, because it's down at the lowest level in a
function called a few billion times for some single user operation.
Well then, first order of business then is to ask your compiler to
optimize, and then /measure/ again!
And if it turns out the compiler isn't able to optimize this
sufficiently for your needs, you might exploit your superior human
knowledge of What's Really Going On(TM). E.g., if you know that
"do_something" doesn't change any of the data passed to it, but the
compiler doesn't know that, then /you/ can possibly optimize better like
float data = {0, 1, 3, 1, 3, 4};
for( int i = 0; i < 16; ++i )
{
do_something( data );
++data[0];
++data[3];
}
But also this needs /measurement/ to verify, and now it is far less
robust code, because it depends on your knowledge that "do_something"
really doesn't change the argument data. So this local optimization may
have as a consequence that you should change the signature of
"do_something" to const argument, so that someone doesn't come along and
change it to change argument data. And having done that, it may be that
the compiler, now better informed, will optimize the loop for you, so
that the rewrite was a waste of time, and should now be changed back!
Disclaimer: I seem to vaguely recall earlier discussions where it has
been pointed out that a compiler really can't assume that const really
means const, and so cannot optimize on that basis. I don't know to what
extent those arguments have been theoretically correct, nor to what
extent they apply to current compilers. So again, /measure/.
Cheers, & hth.,
- Alf