Chapter 13. When to Optimize

Faster, better, cheaper—choose two of the above.

—Old engineering proverb

When developing an application, it is important to consider performance optimizations and apply them where appropriate in the development cycle. Forgetting these optimizations (or getting them wrong) can be expensive to correct later in development.^[1] In this chapter, we follow the various stages of the full product life cycle and consider when and why you might need to include some performance optimizations.

^[1] When I talk about expense, I mean cost in both time and money.

Performance tuning is frequently a matter of tradeoffs. Occasionally, you have the wonderful situation that a change to the application is better in every way: it provides better performance, cleaner code, and a more maintainable product. But more often, the performance of parts of an application are interrelated. Tuning one part of the application affects other parts, and not necessarily for the better. The more complicated the application, the more often this is true. You should always consider how a particular performance change will affect other parts of the application. This means that tuning can be a lengthy process simply because it must be iterative. The full performance-tuning sequence (identifying the bottleneck, tuning, and then benchmarking) is necessary to make sure that tuning one part of the application is not too detrimental to another part.

Performance tuning at the analysis and design phases differs from performance tuning at the implementation phase. Designing-in a performance problem usually results in a lot of trouble later on, requiring a large effort to correct. On the other hand, coding that results in poor performance simply requires a tuning phase to eliminate bottlenecks and is much simpler (and cheaper) to correct. As a rule of thumb, a performance problem created (or left uncorrected) in one phase requires roughly five times as much effort to correct in the following development phase. Leaving the problem uncorrected means that the effort required to correct it snowballs, growing fivefold through each development phase (planning, analysis, schematic design, technical design, construction, deployment, production).^[2]

^[2] The fivefold increase is an average across the phases. Studies of the costs of fixing uncorrected problems have found that some phases have a higher cost than others.

Now on to the specifics. Before discussing when to optimize, I'll start with when you should not optimize.