11.1. Optimize for People First, Resources Later

Note that we didn't say, “…how to avoid running out of ….” There's a good reason for this: If you worry about it from the beginning, you're optimizing for the wrong thing. While you'll see a lot of carping from seasoned professionals on Usenet arguing that such-and-such code isn't as efficient as their latest mutation of it, understand that they're coming from a place where the mind-bending code they've just written is as clear to them as anything else. More often than not, they're coming up with these performance enhancements to make the problem more interesting for themselves.

They would not disagree with the advice we're about to give, however:

Optimize your code for readability and maintainability first; make performance optimizations only after profiling of a working version demands it.

By far the most dominant resource cost in software today is not CPU speed, RAM, or disk space; it's people. The time spent by people developing, documenting, maintaining, inheriting, reading, porting, modifying, enhancing, understanding, or debugging an application is the most precious and scarce resource in information technology. Therefore our advice up to this point has focused on how to develop applications to make the best use of that time.

Also, don't underestimate the ability of Moore's Law to help you. In other words, if you're developing an application that will not be operational for another year and a half, by that time processors will be twice as fast, RAM will be half the price, and disk drives will be twice as big. If you're able to trade developer time for procurement dollars (and it's strange how many companies devalue their employees' time in comparison to their hardware even though their bank account doesn't know the difference) and the problem can be solved more cheaply by better hardware, get it.

There will be plenty of other opportunities to practice writing efficient programs because sometimes you really won't have enough resources to run them, and then you will have to make them do better. Whatever you are developing, though, don't assume you know in advance what resource you may run out of. The aforementioned seasoned professionals know that the ability of even the best of them to predict such things is notoriously unreliable.^[1]

^[1] This is not to say that there aren't occasions when resource limitations are fairly obvious. If you're archiving the entire World Wide Web, you should probably be concerned about disk space before you start. (If you are archiving the entire World Wide Web using Perl, please drop us a line; we have a few questions to ask you.)

We will show how you can optimize your programs for speed, memory, or disk space. However, these are not independent variables; frequently there are trade-offs (e.g., gaining memory at the expense of disk space). Equally common are parallel gains: For instance, as you improve your code style, memory usage may go down and execution speed may go up due to fewer memory accesses.