Reply to Message

Bloat is usually from junk within loops or multiple calls
Probably the biggest runtime bloat factor is extra stuff happening within frequently looped or called code.

This should be a strong indicator of what needs to be optimized, if anything, and the problem gets worse when code is re-used in ways that increase the frequency it is invoked. This applies to the original poster's example, too.

Worse than bloat is exploitability, and this too is often an issue when code is re-used in unexpected ways that bring it to the surface. Writing source code for fast runtime execution rather than source code readability is one good way to increase exploitability risk; another is the use of lean languages that lack sanity-checking, such as C's "copy until nul" functions.

There is a gradient from edge-facing code that has to be protected against exploits, down to deep code that has to be fast and must never crash. Anything that brings the exploitable edge down to this critical code is a big problem, e.g. web browsers that allow web sites to (near-)directly call 3D driver code.

I expect to replace edge-facing code frequently, and I expect vendors to rapidly patch exploitable defects as soon as these are found. Ideally, I'd like vendors to code edge-facing software safely, so it isn't exploitable in the first place. All of that favors source code readability over runtime efficiency; a faster JavaScript interpreter doesn't interest me if every web site can throw junk at it, and it contains exploitable defects.

In contrast, bad driver code can wreck system usability and eat data, as well as bog down performance. So I want that code to be written efficiently, and do not exepct to change it unless there is a VERY compelling reason. The key to that is limiting the ways in which the code can be invoked, to reduce availability for exploitation, and simplify its connections to other code so errors can be avoided.

Where you need speed, you have to optimize, at the risk of source readability and errors. Where you are "close to the metal" e.g. device drivers, core OS code etc. the same applies, with the added constraint that errors become intolerable. To make that work, the code has to be kept trivial in complexity.
Posted by cquirke
22nd Jun 2011