optimizing constant ifs out of loop?

lrtaylor@micron.com lrtaylor@micron.com
Wed Oct 1 16:24:00 GMT 2003



-----Original Message-----
From: Eljay Love-Jensen [mailto:eljay@adobe.com] 
> IF you have NOT profiled the code, then optimizing for performance (in
> lieu of the norm:  readability) is like taking potshots in the dark.

> "Premature optimization is the root of all evil."
> ~ Tony Hoare (often misattributed to Donald Knuth, who was quoting
Tony 
> Hoare)

I kind of get tired of hearing this quote, because it's only partly
true, and it leads people to often write very inefficient code, because
they assume (and I've seen people teach) that they can simply write it
so that it's pretty, and then they can profile the code afterward and
make it run fast.  That's not always true (and it's often very untrue).
While you shouldn't just blindly try to optimize all of your code from
the outset, since you'll often spend more time than is necessary on
sections of the code that have little to no impact, neither should you
not take performance into account while designing and building systems,
especially where performance is a major factor in the success of a
system.  If you fail to do so, you may end up having to rewrite major
portions of the system when you find out that you can't simply optimize
your current code enough.

The key and problem to the statement above is the word "premature".
True, you shouldn't optimize before you need to.  However, the problem
is that people seem to think that this means that you shouldn't optimize
much, if at all, until you've discovered that your system runs too slow,
and that is just plain wrong (and often much too late).  Optimization
(or planning/designing for optimum/sufficient performance) for
performance critical systems (such as mathematical systems, certain
distributed systems, etc.) should start happening from the outset in the
analysis and design phases.  Even waiting until the coding stage can
often be too late, because your design may be fundamentally flawed - at
least for the performance characteristics that you are trying to
achieve.  The key is really just to learn how to analyze and measure
your architecture or design so that you only try to optimize the areas
or designs that you know will likely keep your from reaching your
performance objectives.  Profiling can be part of that, but it shouldn't
necessarily be the crux of it, and it should happen well before the end
of your project!

Now, don't get me wrong, I'm not saying that he shouldn't profile his
code and see where the bottleneck is or that's not what people should do
when they discover that it's not fast enough.  The point is just that
it's not right to state in a blanket manner that you should only
optimize once you've found a problem.

For an excellent discussion on this topic, take a look at Performance
Solutions by Smith, et al.  They cover it pretty well and give you some
of the tools you need to help you determine whether your design is
likely to meet your criteria as well as several performance principles,
practices, patterns and anti-patterns that can be used as you design
your system for performance.

Cheers,
Lyle



More information about the Gcc-help mailing list