First of all, let’s get some definitions out of the way.
Optimisation
“…the process of modifying a system to make some aspect of it work more efficiently or use fewer resources.” 1
Premature Optimisation
“Optimization on the basis of insufficient information.” 2
In other words, premature optimisation is making a modification to some aspect of a system without sufficient information to gauge whether it will make the system more efficient or use fewer resources.
The key point I’m emphasising is “modification”. Other’s have blogged about this in the past; but I still see far too often that “Premature Optimisation” is used as a crutch for programmers and designers to avoid having to think during the design and development phases.
What premature optimisation is not:
- Choosing one design over another because of speed.
- Changing a design to use fewer resources.
- Researching the fastest algorithm to implement a new feature.
- Analysing alternative algorithms to collect resource usage metrics during the analysis phase.
- Changing code that does not work.
Premature optimisation is making changes to existing, working, code either without knowing it will make the code faster or use less resources or not having a requirement to make the code faster or use less resources.
In other words, if the code works as required, don’t change it.
I often see questions like “is using method one more efficient than method two?” with answers like “if one is more efficient than the other its only a matter of several hundred milliseconds; picking on over the other is a premature optimisation.” No, it is not a premature optimisation. You should always know what performance/resource footprint you need to fulfill when designing and writing code. If you have no specific requirement, simply pick the fastest. But, you have to know what is the fastest of a set of alternatives. Asking/testing what is faster than other is not premature optimisation. It’s just proper design and implementation.
Sometimes you must compromise performance and resource usage to maintainability or compatibility. But, making concessions like this are also not premature optimisations. Making design choices should always include all aspects of a system: maintainability (readability, coupling, cohesion, etc.), regulatory compliance, performance, resource usage, requirements, etc. Choice of an algorithm or a faster or less resource intensive method of performing some action should always consider these aspects.
1 http://en.wikipedia.org/wiki/Optimization_%28computer_science%29
2 http://en.wikipedia.org/wiki/Anti-pattern
Great post…
I totally agree that developers use it as another means NOT to think in detail about design – most devs don’t like it when their brain starts to hurt!
A common ripost I hear from agile teams I have work in when perf is mentioned is ‘we can refactor later because we are developing against explict interfaces’.
You emphasized “modification”, but the emphasis should be on “without sufficient information”. Optimization can be really tricky, because it can depend on many factors, including the running machine itself
This article by Joseph Newcomer explains a lot of the pitfalls of optimization
http://www.codeproject.com/tips/optimizationenemy.asp
Mohammad, The point of my post is to point out what premature optimisation is not, what premature optimisation is. I don’t disagree that modification “without sufficient information” for performance increases is indeed premature optimization.
This post addresses responses like “don’t bother implementing your algorithm that way because it is a premature optimisation” to questions like “I’m going to implement this algorithm, is it faster to implement this way.” When you’re implementing an algorithm it would always be implemented so it is as fast as possible.
I agree with you 100%. The whole point of computing is optimization, in a sense. If computers were as slow as humans in crunching numbers, they would be worthless.
Google built their business (at first) with an efficient algorithm. If their algorithm was slow, it would be worthless.
Some algorithms, such as game simulators or other simulators, are mainly designed for speed.
I guess optimization and speed is sometimes not needed (such as in a basic Windows program), but at other times it is critical. Making general statements about “optimization” (or claiming certain optimizations are premature when they are not) doesn’t do a lot of good. If I remember correctly, the original statement had some qualifiers that are not mentioned often.
Yes the original statement is: “We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.”, which is usually misquoted as “premature optimization is the root of all evil”. But, even people who know the original quote use it as justification for not initially implementing the fastest algorithm.