Intent Avoid squandering reengineering effort on needless “optimizations” by verifying where the bottlenecks are.
When should you rewrite a clearly inefficient piece of code?
This problem is difficult because:
- When you are reengineering software, you are likely to encounter many naive algorithms in the legacy code.
- It can be hard to predict what will impact performance, and you can lose a lot of time on pure supposition.
- Optimized code is often more complex than simple, naive code.
Yet, solving this problem is feasible because:
- There are tools to tell you where you may have a performance problem.
Whenever you are tempted to optimize a “clearly inefficient” part of the system, first use a profiler to determine whether it is actually a bottleneck.
Don’t optimize anything unless your profiler tells you it will make a difference.
If you decide to go ahead, prepare benchmarks that will demonstrate the performance gains.
- You do not waste time optimizing something that will not make a difference to overall performance.
- Naive algorithms will survive longer in the system.
The performance improvement that you can gain by optimizing a bit of code depends on how much time the program, spends in that code in a typical run. A profiler will tell you how much time that is.
“Do it, then do it right, then do it fast” is a well-known aphorism that has been credited to many different sources. Very likely its origin is outside of the field of computer science. The rationale behind it is that you risk making a system complex and hard to maintain if you become preoccupied with performance issues too early. Instead, it is better to first find a solution that works, then clean it up once you understand it. Finally, if you can identify any important performance bottlenecks, that is the time to optimize just those parts that will make a difference.
As a corollary, it may even be a good idea to replace a bit of complex, “optimized” code by a simpler, “naive” solution, if that won’t severely impact performance, but will make it easier to make other changes.
See also Davis’ discussion of “Use Profiler Before Optimizing” [Dav95].
If you Refactor to Understand, you will have started the second step to “do it right."