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%. ~Donald E. Knuth
We quoted too little by only saying “Premature optimization is the root of all evil.” Not all of it is bad because there is a small critical chance that we may need it. Sometimes it is too late to optimize after the code goes live in production. Defining DB indexing is one simple example of this critical 3%.
If we revisit the original text(Structured Programming with go-to Statements, 1974, p268), it provides more advice on how we should respond to the need for premature optimization.
- Don’t overthink on grail of efficiency of the application
- Make sure the code/process has been fully identified before deciding on premature optimization
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 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.
