Optimization

  1. Cost-benefit analysis: Does it really matter if a part of your code is slow? This depends on usage patterns and user expectations.
  2. It helps to be aware of language-specific performance issues (especially C++). These issues need to be understood and dealt with in early design stages, because they can affect the design in fundamental ways (e.g. virtual functions being replaced by static polymorphism).
  3. Make use of the large base of existing libraries. Build your application on top of libraries which offer high performance. Writing an efficient libraries is a lot of work; you don't want to do it yourself.
  4. Use a profiler before, during, and after you optimize to gauge improvements and ensure you aren't wasting your time trying to tune a routine that accounts for only 2% of the runtime.
  5. Look for algorithm and data structure (trees, hash tables, spatial data structures) improvements first. These will offer the largest performance savings and will outlive platform-specific tuning. Maybe you have O(N) algorithms which could be replaced by O(logN) ones.
  6. Be aware that what is good for one architecture may be bad for another. If you have to support many platforms, you should code in a way that guarantees good (not necessarily stellar) performance on all platforms. Note that some libraries are able to tune themselves for particular architectures; if you build on top of them, problem solved.
  7. Understand which optimizations the compiler is competent to perform, and let it do them. You should be optimizing at a level above that of the compiler, or you are wasting your time.
  8. Be aware of platform tools: profilers, hardware counters, assembly annotators, etc. Some compilers (e.g. Intel, SGI) have full-blown performance tuning environments.
  9. Experiment with optimization flags. Sometimes higher levels of optimization produce slower code. Measure compile time/execution time tradeoffs: who cares if a 3% performance improvement requires two more hours of compilation? I will sometimes hack up a script to run through the relevant combinations of optimization flags and measure compile time vs run time.
  10. Try using the "assume no aliasing" flag on your compiler to see if there is a big performance improvement. This is a dangerous flag to use, but it provides a quick way to determine if aliasing is an issue. If it is, you might be able to use the restrict keyword to fix the problem.
  11. You can commit efficiency sins of the grossest sort as long as your inner loops are tight. You don't have to avoid slow language features such as virtual functions, new and delete or even scripting (e.g. driving your C++ program from Python/Perl/Eiffel etc.) Just keep these features away from your inner loops. It's all about amortization.
There are many optimizations which are usually useless and only serve to obscure the code. These optimizations make no difference because of modern architectures and compilers:
Tips for efficient code generation on compilers: Index