I recently watched a recorded presentation of Prof.Diomidis Spinellis, author of a couple of world famous books on programming, like "Code Quality". At some point Mr.Spinellis discussed the issue of program optimization and mentioned some famous quotes related to this issue, quotes that were also listed in his "Code Quality" book:
- The First Rule of Program Optimization: Don't do it.
- The Second Rule of Program Optimization (for experts only): Don't do it yet.
These come from M.A.Jackson. It is hard to exaggerate how much I agree.
I would like to add my own rules to the list :-) Maybe others have said similar words, but now I copy from my own brain:
- The 3rd Rule of Program Optimization: Make sense of it in the real world first.
- The 4th Rule of Program Optimization: Measure it and justify it before you commit to it.
Programmers often set sail to optimize a piece of code, just because it is plain for all to see that this piece of code CAN be optimized. However, you should do some serious thinking first to see whether it makes sense to optimize this piece of code. How often is it run, under which paths, how long does it take to execute, etc. For example don't optimize code to turn a 0.1 msec into a 0.01 msec if that runs once every minute.
Does it make sense to optimize a process that is executed once a day, if that process takes 10min, 20min, 120min, 360min? Would it make sense to optimize the 10min to 1min (10/1 improvement), the 120min to 30min (4/1 improvement) or the 360min to 120min (3/1)?
You definitely can't tell the answer by looking at the numbers. Maybe the 360min procedure runs at the end of the day, after all employees are gone, so no one benefits from the improved performance, but then the backups can be scheduled earlier. Or the 120min process runs over lunch break, so having it finished before people return from lunch does not make that much of a difference.
That's the meaning of the 3rd rule, don't look at the code searching for optimizations, look at the real world for optimizations.
The 4th rule is a bit drastic. After you decided to optimize the code, do some measurements. Careful measurements of the old implementation, careful measurements of the new implementation. If the improvement is NOT worth the while, then you might as well scrap the optimization. Throw it away. You thought you had good reason, you made extensive changes but didn't get the improvement you expected; no hurt feelings, just dump it.
Code complexity and maintainability are far more critically important than a minor performance optimization. KISS should be the topmost priority, not writing code that makes programmers feel good about themselves ;-)
Have Fun!
Dimitrios Staikos
