The improvement in speed from Example
2 to Example 2a is only about 12%, and
many people would pronounce that insig-
nificant. 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 dis-
ciplines a 12 % improvement, easily obtained,
is never considered marginal; and I believe
the same viewpoint should prevail in soft-
ware engineering~ Of course I wouldn’t
bother making such optimizations on a one-
shot job, but when it’s a question of prepar-
ing quality programs, I don’t want to re-
strict myself to tools that deny me such
efficiencies.
There is no doubt that the grail of effi-
ciency 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: pre-
mature optimization is the root of all evil.
Yet we should not pass up our opportuni-
ties in that critical 3 %.