|
Performance in a software application is a funny thing. You can't always tell when you have it, but people will certainly let you know if you don't. Sometimes getting better hardware speeds things up without you having to touch a line of code. Even so, there are coding techniques you can use to increase the likelihood that your applications will work better from day 1.
Here's an article on the topic I originally wrote for THE VIEW back in May/June 1999 and which I've revised and updated. I was surprised to find that my sample code was really... fine, even 10 years later. I had to re-run all the timings, though, as my current laptop is MUCH faster than the Pentium IIs I was using back then.
|
Performance, like security, is easy to bolt onto an application after you’ve nailed the functionality.
Raise your hand if you thought I was serious about that. You people with your hands in the air, you really need to read the rest of this article (and you can put your hands down now).
Normally, of course, “performance” is the holy grail, the pot at the end of the rainbow, the thing we worry about once the piece of code is at last working as we expect. “Make it work, then make it fast,” we’re told. I confess to having followed this algorithm myself on occasion. It’s easier and, face it, more interesting, to focus on the functionality. It’s easier to get the code “demo-able,” to show it off to your boss or customer, than to tell her or him that the code isn’t ready yet because it’s too slow.
We’ve all been there, and will be again. Too often, performance is the last-stage optimization phase of a programming project, the part we get to if and when we have time. This is a fact of development life. Of course, the really big performance gains are made possible by tuning the architecture of an overall implementation, or by tuning the algorithm of your program, but it’s also worthwhile to know how to optimize your code.
|
My purpose in this article is twofold: to sketch a top-down perspective on programming for performance, and to provide you with a set of specific coding tips for Lotus Notes/Domino applications that I hope will aid you in achieving not only better code but a higher level of productivity.
For the purposes of this article, I’ll define performance as a goal, where a developer has to achieve program operation with minimum consumption of computing resources. This presupposes, of course, that the program should operate correctly, since no matter how quickly a program executes, it does you no good whatsoever if it doesn’t accomplish the work it is supposed to accomplish. Still, this definition covers a lot of ground. “Minimum consumption of computing resources” could (and does) mean a lot of things: execution time (start to finish), use of memory, use of disk space, and use of network bandwidth. You might think of additional items to add to this list.
It would be a mistake, as is common in day-to-day programming, to focus only on execution time as a measure of performance. Execution time is, of course, a very important measure of performance, and in fact it is the one with which most of the examples in this article are concerned. But the important point to remember is that to do performance tuning you have to do performance measurement. This, fundamentally, is the scientific approach: you can’t understand what you can’t measure, and you can’t improve what you can’t understand.
|
