Real-life optimization work

Posted Nov 6, 2005 9:45 UTC (Sun) by zblaxell (subscriber, #26385)
In reply to: Real-life optimization work by hppnq
Parent article: All hail the speed demons (O'Reillynet)

Actually the car with airbags has probably also lost weight in other places thanks to materials and construction optimizations, and maybe has a more efficient and/or powerful engine. It most likely actually starts *more* quickly now. In my case, it actually does--my current car has airbags and starts in well under a second, whereas my previous car had no airbags and could not leave the safety of park without idling for at least three seconds *after* the starter motor finished getting the engine to run on its own power (and some days that took a while). The new one is bigger and heavier than the old, but consumes half the fuel (another thing naive Newtonian analysis suggests shouldn't happen). There's a lot of complexity in the new system, but it does something useful that the simpler system couldn't do, and the cost is reasonable given the benefits.

Some people are alive today because of airbags--I doubt they would consider them bloat. OTOH, some people do complain about airbags, although they don't use the word "bloat" to describe it ("dangerous" and "explosive" come to mind).

Sometimes software gets better when it gets bigger. A 6809 machine running a 1.87MHz processor doesn't have a complicated buffer cache subsystem, because it would be slower to read and cache data than to reread it from disk every time it is requested and copy it into a cache; however, a P4 machine running a 3.0GHz processor turns a complicated buffer cache subsystem into huge average-case improvements in I/O subsystem performance. Very few users would consider disk cache to be bloat on a modern machine (maybe people who write bootloaders that must share 512 total bytes of binary with a partition table, or embedded systems which use alternatives to cache, like execute-in-place, or high-end database systems which regard *everything* between the backend and the disk as bloat).

Often, bigger software is just bloated. Program A that performs a task in 1000 steps in a loop is generally slower than Program B that performs the same task in only 500 steps, all else being equal. No amount of spiffy new hardware can change the fact that program A is still twice as slow as program B on the same machine. The complaints about bloat start when program A fails to demonstrate useful improvements over program B, especially when program A is new and typically doesn't do everything that program B does.

And why shouldn't people complain when, all else being equal, someone proposes replacing their existing working software with something slower, larger, and more broken? Even entirely new software is bloated if its runtime cost far exceeds reasonable technical requirements for the problem it solves. It's one thing to say "it has a lot of new capabilities", but the people who are complaining care more about things they're doing now, than things they could do at some future time.

The text editor I used in 1991 (vi) is the same text editor I use in 2005, but its performance relative to CPU clock rate has been largely unchanged during that time (with the convenient side-effect that it is now 200 times faster than it was 14 years ago, or put another way, I can start editing a 200MB file today in the same time I used to need to load a 1MB file).

Today I expect a text editor to fit in well under 1MB of RAM (not including the file being edited of course), support all the editing operations vi does, and go from "zero RAM usage" to "editing a 50MB text file" in three seconds or less. It's possible to double the startup speed of vi by removing the recovery feature, so I'm already tolerating nearly 50% overhead in that standard. Anything slower would be bloated--no matter what fonts or rendering capabilities it has. It's certainly possible to achieve this performance with a Unicode-capable, locale-aware text editor--the fact that nobody seems to have managed to do it yet doesn't mean that all known attempts so far haven't been bloated monsters. To the people who are creating these monsters: don't deny this. Your code, or some code you have chosen to depend on, *is* bloated. Please, keep trying until you get it right. It *is* possible.

OTOH, bloat is often tolerable, although still nothing to be proud of. I have a gigabyte of RAM in this laptop because it's easier and cheaper than trying to make a bunch of huge, multi-modular, multi-layered applications smaller.