Skip to content

Instantly share code, notes, and snippets.

@marktriggs
Created March 3, 2023 08:51
Show Gist options
  • Save marktriggs/7f2fea7872f5f6593e36e307df9f9115 to your computer and use it in GitHub Desktop.
Save marktriggs/7f2fea7872f5f6593e36e307df9f9115 to your computer and use it in GitHub Desktop.
the root of all evil
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 as
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 programmer 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 judgements 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. After
working with such tools for seven years, I've become convinced that
all compilers written from now on should be designed to provide all
programmers with feedback indicating what parts of their programs are
costing the most; indeed, this feedback should be supplied
automatically unless it has been specifically turned off.
-- Donald Knuth, 1974
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment