Think globally, optimize locally ...

An early advocate of applying multi-media in computer based training, back in 1984 I started a company developing educational software for use in elementary schools. Perhaps if it was 1994, I would have a lot more nickels in the old retirement jar, but alas, I digress. Back then, we had a whopping 1Meg of RAM to work with on an 80186 architecture, 64K total for process code and data, running a quasi-real time operating system. We had to squeeze a lot of functionality into a tiny space, and performance was always, always, always an issue. If you wrote brilliantly clever, small and tight code you were the envy of all, or at the very at least, a team hero, if only for a day or two until the next beautifully crafted 'while' loop came along, computing the world with the utmost brevity. During this time, I was proud of my ability to shave off a few nibbles here and there in a data structure, tighten up the performance of a loop or two, or a cull a few bytes out of the code segment of the applications I was developing. Those old lessons and skills can die hard in a world that redefines the playing field with, by comparison, a super computer in everyone's handheld.

Not surprisingly, I have come respect engineers that design measurably efficient code, and encapsulate areas that require further analysis under strict APIs. The rest, as they say, is an implementation detail. If I had a nickel for every time I heard a developer announce in an epiphany of clairvoyance "That method will degrade performance!", or something similar, perhaps I would have found another way to retirement by now. This objection comes in all forms too, from the obdurate developer that proclaims "Wait, that function won't be fast enough", to the academically minded one that pontificates "You've got an order N-squared algorithm there. We'd better spend the time to re-formulate it or the system will be slow."

In practice, I have seen even the best developers exhibit as much accuracy in foretelling the bottlenecks of a system in advance of rigorous measurement as my brother-in-law's pet cat might show in predicting the weather a few years hence. Wherever you suspect the time is going, is rarely, if ever, where time is going. With experience, programmers become skilled at first understanding performance requirements for an application, then designing efficient solutions through the application of tried and true patterns, and profiling out performance problem areas through instrumentation and meticulous calibration.

The thing is, 'fast enough' is all relative. To use our example N squared algorithm above, if N is small, there will be no impact on system throughput. If N is large, and the implementation encapsulated, our method can be written quickly and further instrumented so the true impact on throughput can be observed. If, and only if, the code is on the critical performance path, then, and only then it can be optimized with zero negative impact on the rest of the system.

To make matters worse in all this, poor software designs are never made better solely through optimization. And it gets worse yet. Performance enhancements can often obfuscate a good design, especially if the optimizations are not localized. This makes code harder to develop, maintain and ultimately more expensive with no demonstrable positive impact on system performance. I don't know who said this first, but it's a great one-liner, "It is easier to optimize correct code than to correct optimized code".

So, next time we're in development meeting, come with your profiler output clearly demonstrating the top five performance hits on the system and I'd be happy to go over it with you. Otherwise, resist the temptation to declare the likes of "but that is waaaay to slow", and I'll resist the urge to quote Hoare: "Premature optimization is the root of all evil.". Either that, or come with a fistful of nickels. Peace.