home
table of contents
Programming
June 2004
email

A note on optimizing code

Some say that the golden rule about optimizing is “don’t”. This “golden rule” is one of those saws that should be taken with a large grain of salt. It might be better to say: Don’t optimize until you know what you are doing. Be that as it may, there are at least three major areas where one can optimize. They are:

  • Local code optimizations
  • Choice of Algorithm
  • Program structure and data flow
Of these, local code optimization has the least potential for overall improvement. There are a number of reasons why this is so. Many of these optimizations use techniques that are already used by the compiler; i.e., the programmer is only making explicit what the compiler is doing anyway. Even worse, misguided attempts to “optimize” may muck up the code so that the compiled code is slower. For the most part each local code optimization will only have a small effect on the overall performance, the exception being when there is small regions of code which dominate the execution time.

Choice of algorithm is an obvious path to improvement. Indeed, “choosing the right algorithm” is often recommended as the key to optimization. Regrettably, this is an overrated panacea. It is quite true that making poor choices as to which algorithms to use can have an enormous impact on the performance of programs. However implemented algorithms are usually available as canned code. In those cases where algorithm choice matters, one selects (should select) an appropriate package and use it.

In most programs the bulk of the code, particularly that actually written by the programmer, does not not consist of well-defined, clearly delimited algorithms. Rather it consists of “program structure”, i.e., definitions of various sorts, and executive routines that do some work and delegate other work. In practice the most costly thing in large programs is inefficient program structure, work continually repeated because of poor choices in program layering and modularity.

Some of this useless work can be spotted with the aid of a profiler. Spending a lot of the execution time in service utilities, e.g., the storage allocator, can spotlight unnecessary work.

However much of it comes from an overly narrow view of the functional bits and pieces. Two things happen; the interface protocols explode, and the program elements drown in repetitive chatter as they talk back and forth passing small bits of information.


This page was last updated June 1, 2004.

home
table of contents
Programming
June 2004
email