A professional racing team's job is to get its car to the finish line before all the others. The machine itself is important, but it's the hard, painstaking work of the driver and the mechanics that makes all the difference. You might think that's true of computer code, too. Unfortunately, hand-optimization isn't always the best way to get the most performance out of your algorithms. In fact, today it seldom is.
One problem is that programmers' assumptions about how their own code actually works are often wrong. High-level languages shield programmers from the underlying hardware by design. As a result, coders may try to optimize in ways that are useless or even harmful.
Take the XOR swap algorithm, which uses bitwise operations to swap the values of two variables. Once, it was an efficient hack. But modern CPUs boost performance by executing multiple instructions in parallel, using pipelines. That doesn't work with XOR swap. If you tried to optimize your code using XOR swap today, it would actually run slower because newer CPUs favor other techniques.
Multicore CPUs complicate matters further. To take advantage of them, you need to write multithreaded code. Unfortunately, parallel processing is hard to do right. Optimizations that speed up one thread can inadvertently throttle the others. The more threads, the harder the program is to optimize. Even then, just because a routine can be optimized doesn't mean it should be. Most programs spend 90% of their running time in just 10% of their code.
In many cases, you're better off simply trusting your tools. Already in 1975, Fred Brooks observed that some compilers produced output that handwritten code couldn't beat. That's even truer today, so don't waste time on unneeded hand-optimizations. In your race to improve the efficiency of your code, remember that developer efficiency is often just as important.
Programming myth No. 7: Good code is "simple" or "elegant"
Like most engineers, programmers like to talk about finding "elegant" or "simple" solutions to problems. The trouble is, this turns out to be a poor way to judge software code.
For one thing, what do these terms really mean? Is a simple solution the same as an elegant one? Is an elegant solution one that is computationally efficient, or is it one that uses the fewest lines of code?
Spend too long searching for either, and you risk ending up with that bane of good programming: the clever solution. It's so clever that the other members of the team have to sit and puzzle over it like a crossword before they understand how it works. Even then, they dare not touch it, ever, for fear it might fly apart.