Premature Optimization is 97% Evil
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.1
Read the article by Knuth for more context and elaboration. In Perl, a common mistake is to suffix regular expressions with the /o flag. I can personally attest to this being a bad idea: as Knuth predicted, a bug later emerged due to /o being set in one of my scripts. Instead, use qr// to create the expression, and later m/$re/.
# Good to define these early on, # not buried deep in the code. # Use a better variable name. my $re = qr{e/ge}x; … if ($string =~ m/$re/) { …
Inexperienced coders should not fret long over optimizations. First, hammer out something that works. Then have someone review it, or revisit the code some time later, asking:
- Where does a profiler show time being wasted?
- Can anything make the expensive spots less so?
- Would caching of some sort help?
- Does any of the code seem strange or awkward?
- Could a comment help explain the wacky bits?
- Is there any other way to write the code?
- Can the code be reused? Scale to new uses or more input or different output formats?
- In the future, would you code it differently?
- How long would it take to fix any problems? (Managers love time estimates.)
1 Knuth, Donald E. "Structured Programming with go to Statements." Computing Surveys Vol. 6 No. 4, December 1974: 268.