Should we still be optimizing “in the small”?

Question

I was changing my for loop to increment using ++i instead of i++ and got to thinking, is this really necessary anymore? Surely today\'s compilers

Answer 1

Yes, those things are still relevant. I do a fair bit of that kind of optimization but, to be fair, I'm mostly writing code that has to do relatively complex things in about 10ms on an ARM9. If you're writing code that's running on more modern CPUs then the benefits won't be as great.

If you don't care about portability, and you're doing a fair bit of maths, then you might also look at using whatever vector operations are available on your target platform - SSE on x86, Altivec on PPC. Compilers can't easily use these instructions without a lot of help, and the intrinsics are pretty easy to use these days. Another thing that's not mentioned in the document you linked to is pointer aliasing. You can sometimes get good speed improvements if your compiler has support for some kind of "restrict" keyword. Plus, of course, thinking about cache usage can be important. Reorganizing your code and data in a way that makes good use of the cache can result in dramatic speed increases compared to optimizing away the odd copy or unrolling a loop.

As ever, though, the most important thing is to profile. Only optimize code that's actually slow, make sure your optimization actually makes it quicker, and look at the disassembly to see what optimizations the compiler is already doing for you before you try to improve it.

Answer 2

The compiler is in a better position to judge and make such decisions. Micro optimizations you make may come into its way and ultimately miss the whole point.

Answer 3

An interesting observation I've had over the years is that optimized code of one generation back seems to actually be counter-optimized in the following generation. This is i.e. due to processor implementations changing so that if/else becomes a bottleneck in modern CPUs, where pipelines are deep. I would say clean, short, concise code is often the best end result. Where optimization really counts is in the data structures, to get them right and slim.

Answer 4

As others have said, ++i may be more efficient than i++ if i is an instance of some object. That difference may or may not be significant to you.

However, in the context of your question about whether the compiler can do these optimisations for you, in your chosen example it can't. The reason is that ++i and i++ have different meanings - which is why they are implemented as different functions. i++ has to do extra work (to copy the current state before incrementing, do the increment, then return that state). If you don't need that extra work, then why choose that form other the more direct form? The answer might be readability - but it has become idiomatic in C++ to write ++i in these case, so I don't believe readability comes into it.

So, given the choice between writing code that does unnecessary extra work (which may or may not be significant), with no benefit in itself, I would always choose the more direct form. This is not a premature optimisation. On the other hand it's not usually significant enough to get religious about either.

Answer 5

Don't try to guess what your compiler is doing. If you've already determined that you need to optimize something at this level, isolate that bit and look at the generated assembly. If you can see that the generated code is doing something slow that can be improved, by all means fiddle with it at a code level and see what happens. If you really need control, rewrite that bit in assembly and link it in.

This is a pain in the ass, but the only way to really see what is happening. Be aware that all such tight optimizations may become useless once you change anything (different CPU, different compiler, even different cache, etc.) and it's a sunk cost.

Answer 6

Make it right, then make it fast - based on measurement of performance.

Choose algorithms well and implement them in the MOST READABLE way possible. Trade off readability for performance only when you MUST - that is when your user say that performance is unacceptable either in words or by their actions.

As Donald Knuth/Tony Hoare said "premature optimization is the root of all evil" - still true now 30 years later...