|Optimization Question email@example.com (Gunnar Braun) (2000-07-27)|
|Re: Optimization Question firstname.lastname@example.org (Gunnar Braun) (2000-07-30)|
|Re: Optimization Question email@example.com (2000-07-31)|
|Re: Optimization Question firstname.lastname@example.org (David Chase) (2000-08-04)|
|From:||David Chase <email@example.com>|
|Date:||4 Aug 2000 15:54:45 -0400|
I wish, especially in a compilers newsgroup, that people would
think about what a compiler might do for them, let the compiler
do those things, and focus on those things that a compiler is not
likely to discover.
>long SavedLine = 0;
>char SavedTableNr = 0;
>The init is not free, the compiler must get zeroes into those autos
>somehow (CPU time on each invocation of the routine). With the code
>shown it actually appears to be entirely safe to not initialize
If this is trivially true, then it is cost-free with a good compiler,
because the assignments are dead and will be eliminated.
>It is probably possible to eliminate
>one of those two SavedXYZ variable.
And if it is, a good optimizing compiler will get rid of it
with copy propagation.
The earlier advice from Peter Montgomery is better, and if C++ won't
let you constructor a "pointer" to
use a "reference" instead. If those two indices are invariant
across all that code, you should construct that pointer/reference
only once. Given that they look like non-locals (whatever they
are) your compiler is going to be less likely to do this for
you, especially with the odd subroutine call in there.
David Chase -- firstname.lastname@example.org
NaturalBridge Inc -- http://www.naturalbridge.com
BulletTrain bytecode compiler -- when you can't wait for performance
Return to the
Search the comp.compilers archives again.