How Not to Optimize
When people talk about optimizing an application, there is a temptation to immediately think of recoding the hot routines in assembly language or of reaching for one of the
many books about performance optimization that talk about loop unrolling, invariant hoisting, and so on.
These do not represent the best place to start. In general, it is best to avoid optimiza-tions that make the code less easy to read. The best approach is to make minimal changes to the source code or to select improved compiler flags.
It used to be the case that optimization did mean writing in assembly language or manually applying loop transformations in the source. That is why books on optimiza-tions typically have extensive coverage of these topics. However, these optimizations are usually trivial for any modern compiler to do, given the right flags. Using the compiler to do the optimization has several benefits:
n First, the compiler will get the optimization correct. Manually undertaking com-plex instructions can potentially lead to bugs.
n The second benefit is that the code remains manageable. If the details of algorithm change, it will require only the minimal number of modifications to the source
code, and the compiler will reapply the same optimization.
There is a third benefit—that the compiler will do the optimization only if it is likely to result in a performance gain. Some optimizations might be a help on one processor but result in performance loss on a different processor.
Therefore, the important steps are to identify where the time is spent and then deter-mine why the compiler isn’t performing an optimization. Often, solving the problem is simply a minor change to the source code or the addition of a compiler flag.
Having said all that, there will be situations where it is impossible to coax optimal code out of the compiler and where manually optimizing the code is unavoidable. However, even before doing this, consider the gain that the optimization will provide. Doubling the performance of part of the code where 10% of the runtime is spent will result in a 5% gain in performance. This gain needs to be considered in light of the time spent rewriting the code to get the gain and the maintenance costs of the new code.