A Brief Affair With Performance Optimization

When I owned my computer business, I was always trying to find ways to set myself apart from the large and ever-growing pack of so-called "computer consultants." Shortly after the introduction of the IBM PC, it seemed like everyone who owned one would print business cards and then go out and sell themselves as consultants - even though they didn't have any computer experience outside of their own basement. One of the ways I set myself apart from those posers was by offering superior performance - in hardware and software.

On the hardware side, I built and sold IBM AT (80286) compatible computers - but they were much faster than my competitor's 80286 computers. I used my electronics background to design fast systems. I carefully overclocked the CPU, I coupled RLL hard disk controllers with low seek time hard disks, I optimized hard disk interleave, and I installed a minimum of one megabyte of memory so the area above the 640 kilobyte DOS limit could be used as a disk cache. My computers cost about $100 more than my competitor's, but my customers understood why. Unfortunately, my competitive edge was short lived - it wasn't long before other shops in the area started offering similar systems.

On the software side I optimized code. Microsystems Journal ran a series of articles on optimizing assembly language code, so I spent some time trying out different ideas based on their concepts. I ended up with a toolkit of code optimizations that I could use in any language. Most of my small business customers were running accounting applications written in Business Basic (MAS90, ACCPAC) or dBase (SBT, Champion). Whenever one of those customers complained about a report or batch process running too slow, I applied my code optimization toolkit to the code and got it running faster. On rare occasions I would use my assembly language expertise to solve a performance problem (does anyone remember TSRs?).

Eventually 32 bit computers arrived with the 80386, and performance problems were easily solved with a faster computer. The consultant posers were going to school and actually learning the things they claimed to be experts in. I was losing market share. I started to blend in with the pack. I had to do something. I had to do something different.

I decided to go into the mainframe world. Why should I work in a world where computers cost thousands, when I could just as easily work in a world where computers cost millions? So, I enrolled in a school that taught mainframe programming - and while I was at the school I had the opportunity to work with an IBM System 370. The school taught COBOL, C, and Assembly Language - and it was in the Assembly Language course that I decided to use my code optimization toolkit.

From an assembly language standpoint, all CPUs are basically the same - the main difference is the mnemonics. Since I was experienced in assembly language programming, all I had to learn to pass the Assembly Language class was the 370's mnemonics. The lab assignments were trivial and I received perfect grades without trying. I was bored, so I decided to stir things up a bit. Instead of writing code the way the textbook dictated, I would use my code optimization toolkit to write very fast code that achieved the same results.

I'll never forget watching the instructor as he graded my first optimized lab assignment. He picked up his red pencil immediately - ready to mark up my "wrong" code. Then he paused, cocked his head, and put his pencil back down. After a few minutes, he graded my assignment and went on to the next one. When I got the assignment back, I saw that it received a perfect grade and a note: "This isn't what the textbook taught, but there is no doubt it would execute faster."

It turned out my instructor's "real job" was working as a lead programmer at TRW (now a part of Experian). At the end of the course I gave him my card, and shortly after I graduated he gave me a call. He wanted me to try my optimizations on some of their programs that were running a little slow. I made changes to a handful of printouts, got paid, and never heard from them again.

My plans to work in the mainframe world never panned out. Businesses started unplugging their mainframes and switched to LANs. I managed to pick up a few municipalities as customers though - they used me to integrate their LANs with their mainframes.

Nowadays there isn't much need for performance optimization. Computers today are very fast and very cheap. Today's 32 bit CPUs running at 2 GHz are 4000 times faster than the original IBM PC. Modern compilers do code optimizations automatically. Performance problems are solved with more servers.

My brief affair with performance optimization was fun and educational. I still put my code optimization techniques to work today - not in a way where better performance is a goal, but rather as a way to avoid writing sloppy code.