Cook Computing

Premature Optimization

Premature Optimization by Justin Rodd (via Almost Perfect) suggests the famous quote originating from Tony Hoare and restated by Donald Knuth: "Premature optimization is the root of all evil". I've always thought this quote has all too often led software designers into serious mistakes because it has been applied to a different problem domain to what was intended.

The full version of the quote is "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." and I agree with this. Its usually not worth spending a lot of time micro-optimizing code before its obvious where the performance bottlenecks are. But, conversely, when designing software at a system level, performance issues should always be considered from the beginning. A good software developer will do this automatically, having developed a feel for where performance issues will cause problems. An inexperienced developer will not bother, misguidedly believing that a bit of fine tuning at a later stage will fix any problems.

I've worked on systems where the architects adhered to "Hoare's Dictum". All goes well until realistic large-scale testing is performed and it becomes painfully obvious that the system is never going to scale upwards. Unfortunately by then it can be very difficult to fix the problem without a large amount of re-design and re-coding.

On a smaller scale I'm reminded of a configuration client I use regularly. It communicates with the server via DCOM and makes so many DCOM calls that it is very irritating to use over a slow network connection. I've looked at the code and I suspect that simplicity of design was thought to be the better approach instead of a more complicated design which would have resulted in far fewer DCOM calls. Again, optimizing this code would require a lot of re-working: optimization after a design has been implemented nearly always involves much more work than incorporating it into the original design.