Prefactoring

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 ...