Saving Programming Cycles

by Don Schullian

There are (usually) several ways any one routine can be made to run faster, though I've always felt that it is just as important, or even MORE important, to be able to understand the code 6 months down the road that to shave off a few nano-seconds.

Little tricks like: Using LONGs as loop counters and counting backwards (to zero) when possible. Dropping some code into ASM, REGISTER variables, etc. all play a part but.... Unless a given routine is used so often and is so heavy into number crunching that it is bogging down the whole program I don't spend a lot of time looking for ways to save a nano or two.

I'm not a lover of GLOBALs but use them where they're indicated. Just make sure you've got some naming convention for them so you can see, at a glance, that they're g_GlobalVariables.

Figure it this way: You spend 2 hours shaving .001 of a second off the routine. The routine is called 10 times during normal usage of the program in one session. The program is used once a day. 10 years from now you will have hit the break even point for time expended and your user will never notice one way or the other.

Optimize? Sure! But don't get caught up in it. The little 'tricks' will come along, one at a time, and drift, quietly, into your code over the years.

The biggest time saver is clean, well documented code with good, descriptive variable names. When something goes wrong (and it will) 6 months, a year, or 5 years from now you'll be glad you put some effort into the coding when you can find and fix the bug, or update a feature, in a matter of a few minutes rather than a few days or weeks.