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

["Jeffrey R. Carter" <spam.jrcarter.not@acm.nospam.org>]

Jeffrey Creem wrote:
> 
> 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.

The rule is, "1st get it right, then make it fast." If you did a poor 
job up front, you didn't get it right 1st. And usually no amount of 
small, local optimization such as the OP is discussing will help you.

> 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.

That's pretty much the definition of premature optimization: extra 
(sometimes substantial) effort spent on obfuscation "for speed", done 
early, without any measurements to indicate that it will help.

-- 
Jeff Carter
"Hello! Smelly English K...niggets."
Monty Python & the Holy Grail
08