Thou shalt have no other gods before the ANSI C standard 1417

Randy Howard

This is the key point. The long term flexibility is extremely valuable. That same effect occurs when you implement an algorithm that is correct no matter what the underlying register size, word size, character size, character sign bit, whether zero-length files are supported, whether math errors are handled by errno, matherr(), exceptions, or encoded NaNs.

Occasionally the difficulty is such that the effort may not pay off, but that is quite rare, so any such exceptional case needs a lot of justification. The default buttumption is that it will pay off, we just can't measure how big a win it will be before it happens.

Many times performance is used as an excuse to avoid the "skull sweat" required to do the job right the first time. But this is usually just an excuse -- a groteqsque form of premature optimization.

At one major software company faced with an OS upgrade there was a big debate over a hand-tuned buttember routine that was a legacy of the previous OS version. It was considered to be critial to the performance of a flagship application. The cleaned up version ran a few cycles slower. The debate raged quite a while because the programmers feared that people would reject a sluggish "upgrade". The debate ended when some spoilsport instrumented the critical routine with a counter. By running a long term exerciser they were able to measure how many times the critical routine was called. The count and the extra cycles amounted to less than one second of extra time per hour of runtime.

They shipped the cleaned up code.

But that's not the point of the story. The point is that there was no justification for the hand tuning of the supposedly critical routine in the first place. Somebody decided to optimize something that didn't need to be optimized.

A second example has to do with languages. Microsoft(R) C for PC-DOS and OS-2 had a really bad heap manager. It was designed to perform well on trivial benchmarks. Its free space manager was implemented as a singly linked list, probably to conserve space. And free() just marked blocks free without consolidating them. Which meant two things. 1) the RTL did well on trivial benchmarks, and 2) the heap manager pounded memory into tiny little fragments and programs would report "out of memory" when there was 100s of K free.

I released a complete, ANSI-standard, replacement heap manager that used a doubly linked list and did eager consolidationm including legacy feaure support such as realloc of a recently free'd block preserving the original contents (per ancient unix semantics). I could not believe the reactions from people who used it -- their grabreastude was profuse.

The point is that doing it right always pays off. It's just hard to predict how fast the benefits will accrue.

Note that because the free list was much shorter the heap manager ran up to 200x faster than Microsoft(R)'s version (average was a bit over 100x faster). I offered it to Microsoft so they could distribute it or incorporate it, but they said there was no point to it. I was given to understand that their compiler was best on the benchmarks they liked so they didn't want to change anything.

tj3