The evils of optimization

Donald Knuth once said "premature optimization is the root of all evil". Actually some guy named Tony Hoare said it first, and Knuth was just quoting him, but I don't know who Hoare is, so I'm quoting Knuth. In any case, it refers to a tendency of programmers to try to fine tune a program before determining where the real problems are. The end result is a lot of programmer thinking time is spent improving things that don't really matter. This isn't the same thing as "rearranging chairs on the deck of the Titanic", more like trying to make an M1 Abrams tank faster by changing the aerodynamics.

I discovered an essay on the subject by Joseph M. Newcomer. I also don't know who Newcomer is, but I like his essay so I'm quoting him here too. The essay, Optimization: Your Worst Enemy, is a very experience-based story about why premature optimization is so evil. If you can make it through the tech-speak (sample quote: "Even I can figure out how to get CWnd::OnAnything to inline-expand to a call on DefWindowProc."), the tales he tells underscore that it is not merely a distraction, but actually harmful, to optimize uninformed.

Perhaps the best example of pure programmer stupidity in "optimizing" code occurred when I was porting a large library we used for our research project.
...
The port mostly worked, but we had a really strange problem that showed up only under some rare conditions, but which crashed the program using the library. I started looking. The heap was damaged. When I found how the heap was being damaged, it was being damaged via a bad pointer which allowed a store into a random place in the heap. OK, how did that pointer get bad? Four levels of storage damage down, and after 12 solid hours of debugging, I found the real culprit.
...
When I confronted the programmer, he justified it by explaining that he was now able to zero out two pointers with only a single doubleword store instruction (it wasn't an x86 computer, but a mainframe), and wasn't that a clever optimization? Of course, when the pointers became 32-bit pointers, this optimization only zeroed one of the two pointers, leaving the other either NULL (most of the time), or, occasionally, pointing into the heap in an eventually destructive manner. I pointed out that this optimization happened once, at object creation time; the average application that used our library created perhaps six of these objects, and that according to the CPU data of the day before I'd spent not only 17 hours of my time but 6 hours of CPU time, and that if we fixed the bug and ran the formerly-failing program continuously, starting it up instantly after it finished, for fourteen years, the time saved by his clever hack would just about break even with the CPU time required to find and fix this piece of gratuitous nonsense. Several years later he was still doing tricks like this; some people never learn.

[via flounder.com]