Use the Right Algorithm and Data Structure
Jan Christiaan “JC” van Winkel
A big bank with many branch offices complained that the new computers it had bought for the tellers were too slow. This was in the time before everyone used electronic banking, and ATMs were not as widespread as they are now. People would visit the bank far more often, and the slow computers were making the people queue up. Consequently, the bank threatened to break its contract with the vendor.
The vendor sent a performance analysis and tuning specialist to determine the cause of the delays. He soon found one specific program running on the terminal that consumed almost all the CPU capacity. Using a profiling tool, he zoomed in on the program and he could see the function that was the culprit. The source code read:
for (i=0; i
n=strlen(s);
for (i=0; i<n; ++i) {
if (... s[i] ...) ...
}97 Things Every Programmer Should Know
?
???????????????Everyone knows the adage “first make it work, then make it work fast” to avoid the pitfalls of micro-optimization. But the preceding example would almost make you believe that the programmer followed the Machiavellian adagio “first make it work slowly.”
This thoughtlessness is something you may come across more than once. And it is not just a “don’t reinvent the wheel” thing. Sometimes novice program- mers just start typing away without really thinking, and suddenly they have “invented” bubble sort. They may even be bragging about it.
The other side of choosing the right algorithm is the choice of data structure. It can make a big difference: using a linked list for a collection of a million items you want to search through—compared to a hashed data structure or a binary tree—will have a big impact on the user’s appreciation of your programming.
Programmers should not reinvent the wheel, and should use existing libraries where possible. But to be able to avoid problems like the bank’s, they should also be educated about algorithms and how they scale. Is it just the eye candy in modern text editors that makes them as slow as old-school programs like WordStar in the 1980s? Many say reuse in programming is paramount. Above all, however, programmers should know when, what, and how to reuse. To do that, they should have knowledge of the problem domain and of algorithms and data structures.
A good programmer should also know when to use an abominable algorithm. For example, if the problem domain dictates that there can never be more than five items (like the number of dice in a Yahtzee game), you know that you always have to sort at most five items. In that case, bubble sort might actually be the most efficient way to sort the items. Every dog has its day.
So, read some good books—and make sure you understand them. And if you really read Donald Knuth’s The Art of Computer Programming (Addison-Wesley Professional), well, you might even be lucky: find a mistake by the author, and you’ll earn one of Don Knuth’s hexadecimal dollar ($2.56) checks.