3.10. Speeding

Jerry Weinberg tells the story of two groups, both working on solving the same problem. Jerry's group created a solution that worked correctly but was slower than the other group's. The other group developed a solution that was fast but did not work for all input values.

The other group leader referred to the differences by belittling the correct solution for running so slowly. Jerry replied by asking when the other group would have a usable solution.

It is usually easier to transform a correctly designed "slow" system into a fast enough system than it is to alter an incorrect fast system. Even if the slow system cannot be transformed, it can be used as a reference platform for functionality tests. ^[*]

^[*] Andrew Koenig says, "When they tell you to avoid premature optimization, they don't mean it's OK to use a quadratic algorithm rather than a linear one, or even an n-log-n one."

Do not waste time making assumptions about performance. Use a profiler to measure performance so that you can focus on a handful of key bottlenecks. Jim Batterson, a fellow consultant, tells the story:

I know that when I was really concerned about efficiency, the best thing I had was a monitoring tool that would tell me where I was spending my time. It was always true that I was spending about 90% of my time on about 10 lines of code, or one little subroutine or one read to a file that was done over and over again. You could optimize the hell out of the rest of the system and never get more than a 10% improvement, or you could optimize that one part and make that baby fly.

Once you have determined the location of the bottleneck, you can create a solution. Selecting a different algorithm often yields the greatest performance gains. For example, a quicksort algorithm works better than a bubble sort most of the time.

With object-oriented programs, high levels of abstraction can be the cause of bottlenecks. Fewer layers of abstraction decrease the number of method calls and thus the calling overhead. Sometimes more tightly coupled objects can eliminate overhead (e.g., sending messages in internal format between computer systems, instead of in a standard text format).

DON'T SPEED UNTIL YOU KNOW WHERE YOU ARE GOING

Make the system right, before you make it fast. ^{[ ]}

^{[ ]} This is covered in The Elements of Programming Style .

OSF UNIX

The original OSF Unix was designed with several layers of abstraction. The virtual memory subsystem was written as an abstraction layer. This design made it easy to port the system between machines that used different virtual memory mechanisms. It turned out that this abstraction affected performance dramatically. To speed things up, direct use of the processor's virtual memory hardware replaced this abstraction.