Performance impact of using 'break' inside 'for-loop'

Question

I have done my best and read a lot of Q&As on SO.SE, but I haven't found an answer to my particular question. Most for-loop and break related question refer to nested loops, while I am concerned with performance.

I want to know if using a break inside a for-loop has an impact on the performance of my C++ code (assuming the break gets almost never called). And if it has, I would also like to know tentatively how big the penalization is.

I am quite suspicions that it does indeed impact performance (although I do not know how much). So I wanted to ask you. My reasoning goes as follows:

Independently of the extra code for the conditional statements that trigger the break (like an if), it necessarily ads additional instructions to my loop.

Further, it probably also messes around when my compiler tries to unfold the for-loop, as it no longer knows the number of iterations that will run at compile time, effectively rendering it into a while-loop.

Therefore, I suspect it does have a performance impact, which could be considerable for very fast and tight loops.

---

So this takes me to a follow-up question. Is a for-loop & break performance-wise equal to a while-loop? Like in the following snippet, where we assume that checkCondition() evaluates 99.9% of the time as true. Do I loose the performance advantage of the for-loop?

// USING WHILE
int i = 100;
while( i-- && checkCondition())
{
    // do stuff
}


// USING FOR
for(int i=100; i; --i)
{
    if(checkCondition()) {
        // do stuff
    } else {
        break;
    }
}

I have tried it on my computer, but I get the same execution time. And being wary of the compiler and its optimization voodoo, I wanted to know the conceptual answer.

---

EDIT:

Note that I have measured the execution time of both versions in my complete code, without any real difference. Also, I do not trust compiling with -s (which I usually do) for this matter, as I am not interested in the particular result of my compiler. I am rather interested in the concept itself (in an academic sense) as I am not sure if I got this completely right :)

Answer 1

The principal answer is to avoid spending time on similar micro optimizations until you have verified that such condition evaluation is a bottleneck.

The real answer is that CPU have powerful branch prediction circuits which empirically work really well.

What will happen is that your CPU will choose if the branch is going to be taken or not and execute the code as if the if condition is not even present. Of course this relies on multiple assumptions, like not having side effects on the condition calculation (so that part of the body loop depends on it) and that that condition will always evaluate to false up to a certain point in which it will become true and stop the loop.

Some compilers also allow you to specify the likeliness of an evaluation as a hint the branch predictor.

If you want to see the semantic difference between the two code versions just compile them with -S and examinate the generated asm code, there's no other magic way to do it.

Answer 2

The only sensible answer to "what is the performance impact of ...", is "measure it". There are very few generic answers.

In the particular case you show, it would be rather surprising if an optimising compiler generated significantly different code for the two examples. On the other hand, I can believe that a loop like:

unsigned sum = 0;
unsigned stop = -1;
for (int i = 0; i<32; i++)
{
    stop &= checkcondition();  // returns 0 or all-bits-set;
    sum += (stop & x[i]);
}

might be faster than:

unsigned sum = 0;
for (int i = 0; i<32; i++)
{
    if (!checkcondition())
        break;
    sum += x[i];
}

for a particular compiler, for a particular platform, with the right optimization levels set, and for a particular pattern of "checkcondition" results.

... but the only way to tell would be to measure.