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.
Related Topics
Privacy Policy, Terms and Conditions, DMCA Policy and Compliant
Copyright © 2018-2023 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.