Re: sub-optimal code for packed boolean arrays -- bug or inherent limitation

[Jeffrey Creem <jeff@thecreems.com>]

Jeffrey R. Carter wrote:

> My reaction is due to an allergy to premature optimization, the root of 
> all evil.
> 

"Premature Optimization" is one of those pieces of conventional wisdom 
that gets repeated often but which is in fact not the problem at 
all..Not really.

In any real-world problem, you rarely get to spend 6 months making it 
faster because you did such a poor job up front in designing the problem.

Often, by the time one has created a design mess that is slow 
everywhere, spending the short time optimizing the scary loops is not 
enough because the design itself is broken.

The real problem is not so much premature optimization but crazy 
micro-optimizations done early that also hurt maintainabilty/clarity of 
the code and often do little if anything to actually make the code faster.

Spending time up front thinking about the overall design and even 
worrying a little about specific performance details when not taken to 
the extreme and when done with the benefit of metrics backed experience 
(v.s. I heard one time that compiler X was slow on this) is actually not 
all that bad.

This is of course especially true when one considers that by the end of 
the project when you go to start profiling the code to find the hotspots 
and find out that your lousy tool set does not support profiling with 
programs with tasks, or does not support profiling of non-trivial 
programs at all.