Software development has some consistent goals. We want the software to be as fast as possible, as small as possible, to work as well as possible, and to be done as soon as possible. Naturally there tend to be trade-offs between these goals: the fastest algorithm may require more storage space, the algorithm that requires the least space may be complicated and prone to errors, extensive testing may delay the release. We decide which goals take priority and what values are acceptable for each. But how to choose?
In some cases, optimizing for speed and size makes a lot of sense. If a loop will execute ten thousand times, a one-millisecond delay in each loop is likely to be unacceptable. If there are ten million items to be stored, requiring an extra byte for each item can make a difference, even with today’s storage allocations. Even when not under tight constraints, all things being equal, we’d like to optimize our performance.
In some cases, though, it’s better not to optimize. I’m not talking about avoiding premature optimization – I’m talking about not optimizing at all. For example, suppose you have an object which will be instantiated a few dozen times (with each instantiation being stored on disk) and there are two ways you can code it. One will require an additional string value, the other will simply perform some calculations (perhaps a dozen lines of code) each time the object is loaded. The time to do this calculation will be unnoticeable. Should the value be included or not?
At first glance we might say, sure, the calculation time is insignificant so we might as well do it. On the other hand, since the object will only be instantiated a few times, the extra space requirements are also insignificant; it simply makes no difference to the performance whether we store the extra item or not.
Does that mean it doesn’t matter which decision we make? In this case….no. We also have to factor in the complexity of the calculation: not to the computer, but to the programmer. Adding extra code makes it that much more likely that a bug will slip in someplace; given two options where neither has a performance benefit, we should opt for the simpler one. In this case, then, I would choose to use the extra item, not to save the calculation time for the computer, but to save the mental energy of the programmer by making the code that much simpler.