Whenever a promising new programming practice is discussed I inevitably hear the comment "That might hurt performance," meaning that it will consume more computer cycles than a more traditional design. What I think I am actually hearing is "This strange new programming style confuses me. If it is less efficient, then I can continue programming the same way as before."
I would like to see this knee-jerk response discredited once and for all. Optimizing code is comparatively easy. Everyone claims to know how to do it. Everyone also knows how to make code unreadable and unmaintainable. Good design is genuinely hard. A numerical calculation can be rewritten eventually to achieve maximum efficiency (on a given compiler on a given machine). We never come close to an optimum design. After a month, any design begins to show flaws.
I recommend everyone concentrate on design first and save the easier optimization for later. If you have done your homework, really inefficient designs will be obvious, and you will not have to remind yourself to avoid them. Anyway, most optimization is local. Design is global. Wait until you can actually profile your running code and see where the real bottlenecks are. Many have noticed that programmers are very bad at predicting the actual distribution of runtime in their programs. Some code will take much less of the total runtime than you expected, and you will not need to optimize it, even if it is much less efficient than possible. Some code you had not given much attention to will take too much time. When you find a local piece of code that is suffering from too much encapsulation (costly method calls or object creation), then you can break that encapsulation and optimize locally. But you can keep that code integrity elsewhere when it does not slow you down. If you start out writing assembly code, then you will end up doing it everywhere, including the ninety-five percent where you do not need it.
Remember programs age and become obsolete quickly because CPU's double in speed every year or two. If you are not planning to take advantage of the next speedup by improving your designs, then your code is going to be obsolete much sooner.
In "Literate Programming," Donald Knuth wrote "We should forget about small efficiencies, about 97% of the time. Premature optimization is the root of all evil." The critical word is premature. I am not against optimization. I am just against unnecessarily poor designs that are justified in the name of optimization.
It is easier to optimize correct code than to correct optimized code. Premature optimization actually hinders optimization in the long run. Unnecessary optimization distorts designs, destroys modularity and information-hiding, and makes code much harder to modify. Latent bugs take longer to find. We often discover by profiling, or by changing machines or compilers, that we misjudged the computational effort of our code. Guess what? Now, optimization is much harder than it had to be.
Bill Harlan, 1997
Return to parent directory.