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

In general, no. Compilers are much better at doing small, straightforward micro-optimizations like this across your entire code base. Ensure that you are enabling your compiler here, by compiling your release version with the right optimization flags. If you use Visual Studio, you might want to experiment with favoring size over speed (there are a lot of cases where small code is faster), link-time code generation (LTCG, which enables the compiler to do cross-compiland optimizations), and maybe even profile-guided optimization.

You also need to remember that the vast bulk of your code won't matter from a performance perspective - optimizing this code will have no user visible effect.

You need to define your performance goals early on and measure frequently to make sure you're meeting them. When outside of your goals, use tools such as profilers to determine where the hot spots are in your code and optimize those.

As another poster here mentioned, "optimization without measuring and understanding isn't optimization at all - its just random change."

If you have measured and determined that a particular function or loop is a hotspot, there are two approaches to optimize it:

• First, optimize it at a higher level by reducing invocations of the costly code. This will usually lead to the most benefits. Algorithm level improvements fall into this level - an algorithm will a better big-O should result in running the hotspot code less.
• If calls cannot be reduced, then you should consider micro-optimizations. Look at the actual machine code that the compiler is emitting and determine what it is doing that is the most costly - if it turns out copying temporary objects is occuring, then consider prefix ++ over postfix. If it's doing an unnecessary comparison at the beginning of the loop, flip the loop into a do/while, and so on. Without understanding why the code is slow, any blanket micro-optimizations are next to useless.