Rules of program optimization

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

Comments

[Giorgos Keramidas]

Excellent points!

Another thing I found useful when applying optimizations is:

Use unit tests.

I can't really remember all the times a unit test has saved the day when I'm applying refactoring changes or optimizations. One of the most recent examples is a library function that parses pairs of IPv4 network address and (optional) address-masks. By adding units tests that should pass for the most common formats ("10/8", "10.0/12", "192.168.1/16" or even "0/0" and "0/255.255.255.0") I uncovered a bug that had been lurking in the code since the last time I touched it this summer.

Having a set of unit tests that were all successful I started making the optimization I had in mind. At the end of the day I knew that I had not broken any of the working cases, and the optimizations were committed and pushed to our main branch.

This and other past experiences make me feel strange and very very cautious every time I have to add optimizations to a piece of code without an accompanying test suite.

BTW, is the video of prof. Spinellis online in a publicly accessible place? Can we fetch and view it too?

[Dimitris Staikos]

This is the link to the video (the talk is in Greek): https://www323.livemeeting.com/cc/usergroups/view?id=dnzad1-1

You are absolutely right about the unit tests. They are needed for all kinds of refactorings, not just optimizations.