This just defers the optimization process by one step. It's hard to improve something without measuring it first, but either you know where your inner loop is

This just defers the optimization process by one step. It's hard to improve something without measuring it first, but either you know where your inner loop is or the profiler tells you. Now you've still got to improve that bottleneck somehow and take into account all those complicating factors. I've seen very unexpected results doing this. In one case, I put the inner loop in a separate function to enable swapping implementations and make it simpler to time. Surprisingly, the overall program ran faster without any other changes. Just pulling the inner loop into a function of its own sped things up. My best guess was that the compiler was willing to put more effort into optimization on the smaller function. This contradicts common wisdom about function call overhead, and it also shows another level of complexity in the problem: Some compiler optimizations are exponential in their cost, so they punt if you put too much of your code in one block or function. Also note that I wasn't able to prove this is what happened. It's just my best guess based on what I was able to see and infer.