* * * * *
                                        
                             Premature optimization
                                        
> > “We should forget about small efficiencies, say about 97% of the time.
> > Premature optimization is the root of all evil.”
> > 
> > “Knuth, Literate Programming, 1992, p28.”
> > 
> 
> Nobody wants to argue with Knuth—it is the equivalent of arguing against
> the second law of thermodynamics. However, the problem here is that too
> often people misunderstand what Knuth was getting at.
> 

“Mature Optimization [1]”

I often feel as if the industry has gone off into collective insanity because
of Knuth's [2] quote, that concerns for programming efficiency are brushed
aside because, well, optimization is eeeeeeeeeevil, people! Eeeeeeevil! (And
if you really want to go down this rabbit hole [3], writing code is a form of
premature optimization, because it's already been written [4]. Even figuring
out the problem is a form of premature optimization since someone already
solved it [5].)

But the article points out that Knuth has been misquoted. Or rather,
selectively quoted. The full quote from Knuth's book _Literate Programming_
[6]:

> The improvement in speed from Example 2 to Example 2a is only about 12%,
> and many people would pronounce that insignificant. The conventional wisdom
> shared by many of today's software engineers calls for ignoring efficiency
> in the small; but I believe this is simply an overreaction to the abuses
> they see being practiced by penny-wise-and-pound-foolish programmers, who
> can't debug or maintain their “optimized” programs. In established
> engineering disciplines a 12% improvement, easily obtained, is never
> considered marginal; and I believe the same viewpoint should prevail in
> software engineering. Of course I wouldn't bother making such optimizations
> on a one-shot job, but when it's a question of preparing quality programs,
> I don't want to restrict myself to tools that deny me such efficiencies.
> 
> There is no doubt that the grail of efficiency leads to abuse. Programmers
> waste enormous amounts of time thinking about, or worrying about, the speed
> of noncritical parts of their programs, and these attempts at efficiency
> actually have a strong negative impact when debugging and maintenance are
> considered. We should forget about small efficiencies, say about 97% of the
> time: premature optimization is the root of all evil.
> 
> Yet we should not pass up our opportunities in that critical 3%. A good
> programmmer will not be lulled into complacency by such reasoning, he will
> be wise to look carefully at the critical code, but only after that code
> has been identified. It is often a mistake to make a priori judgments about
> what parts of a program are really critical, since the universal experience
> of programmers who have been using measurement tools has been that their
> intuitive guesses fail.
> 
> “Knuth, Literate Programming, 1992, p28.”
> 

Another article to read about this: The Fallacy of Premature Optimization
[7].

[1] http://cowboyprogramming.com/2007/01/04/mature-optimization-2/
[2] http://en.wikipedia.org/wiki/Donald_Knuth
[3] http://en.wikipedia.org/wiki/Rabbit_hole
[4] http://www.lazyweb.org/
[5] http://www.lazyweb.org/
[6] http://www.amazon.com/exec/obidos/ASIN/0937073806/conmanlaborat-
[7] http://www.acm.org/ubiquity/views/v7i24_fallacy.html

Email Sean Conner at sean@conman.org

.