Is Source-Code Optimization Worthwhile?

nwetters asks: "I'd like my programs to run as fast as possible, and there are some great books (e.g. High Performance Computing) that give examples of loop optimizations and unit-stride memory use. However, I've heard that modern compilers will automatically optimize even the worst of my cludge. Should I bother with manual tweaking, or leave it up to the compiler? "

Comments

"It Depends"

[V. Mole]

I'm sure there are innumerable ways to screw the compiler. As far as I know, no optimizer yet written converts bubble sorts into quicksorts. That said, you shouldn't worry about optimizing your loops before you've designed you program and picked appropriate algorithms. My theory is to design and code primarily for correctness, reliability, flexibility and maintenance. If the result is fast enough/small enough, then I'm done. If it's too slow (or too big, or whatever), then put it under a profiler and start picking. But definitely don't waste hand optimizing code until you've profiled it to make sure you're optimizing the *right* code!

That doesn't mean you should ignore stuff like memory stride and loop invariants, etc while coding, just because the compiler can fix it. For one thing, who knows what compiler/machine you're going to be using tomorrow? Code optimizers are stupid and conservative, and it doesn't take much to make one "give up" and go with "slow but correct". Another thing is that a lot of code that does confuse the optimizer is likely to confuse a future maintainer as well.

Only if you do a few things first...

[blahedo]

Sure, go ahead! But before you do, you should do a few other things:

• First, tidy up your code. Fix the indentations, elabourate the variable names, make it generally more readable.
• Then, comment it well.
• That done, write out your maintainer-level documentation, which includes all of your high-level algorithms.
• Verify that these algorithms are correct.
• Check the complexity of these algorithms. The real place to shave off time is if you can lower your running time by an O(n) or two.
• Once you've fixed your algorithms, update your documentation.
• And now, after you've done every other improvement you can think of... save a copy of your code.
• Run a profiler on your code.
• If you really still feel like it's too slow, then go ahead and optimise it in the places the profiler picks out as taking a lot of time.

The upshot is, optimising is never a bad thing. It's just an extremely low priority thing. I can't tell you how many of my students I've seen performing low-level optimisations on O(n^3) loops that could have been reduced to O(n lg n) or less. Don't waste your time optimising in the wrong places, and really, make sure you've done everything else first....