0

Which would be more efficient?

if(foo != 0)
{
    bar += foo;
}

or

bar += foo;

Assuming foo could have a decent chance of being 0 (say 25% but could make other assumptions on percentage, obviously 0% would mean the latter is always more efficient)

Is there a concensus on when you should use one over the other, or do people do things like profiling to determine the actual more efficient expression?

Rael
  • 41
  • 5
  • 15
    Such micro optimizations should be avoided until you profile and find out there is an issue with the code. Code for readability and maintainability and only go after performance once you know you need it. – NathanOliver Mar 31 '16 at 15:42
  • Can we assume that the `+=` operator is the built-in one, and it's not overloaded? – anatolyg Mar 31 '16 at 15:43
  • @ anatolyg how would that matter as both use the same operator? – uSeemSurprised Mar 31 '16 at 15:45
  • I think this depends on the compiler. The C code doesn't say anything about how the instructions are performed. So, I would suggest using the second one, since it makes the code easier to read. – WhatsUp Mar 31 '16 at 15:45
  • 1
    I am surprised. Both GCC and clang failed to eliminate excess comparison even for trivial types: https://godbolt.org/g/XK5FL1 – Revolver_Ocelot Mar 31 '16 at 15:48
  • 1
    Almost certainly not. It's hard to say on modern CPUs but a test for zero is likely to take about the same time as an addition, and then we have to skip the addition. So you are trading one instruction for more than one. – jcoder Mar 31 '16 at 15:51
  • 9
    It would be more efficient if you stop premature optimization and focus writing readable code. – Slava Mar 31 '16 at 15:52
  • It would really depend on what hardware you are running on. Optimizations like this are generally best left to the C++ compiler's optimizer, since it will inevitably be better-aware of the various tradeoffs involved than you are (especially if you are writing portable code and can't even predict what hardware it will eventually be compiled for). – Jeremy Friesner Mar 31 '16 at 16:04
  • @uSeemSurprised The point I believe @anatolyg was making is that if `+=` has been overloaded to something that is computationally "slow", then a condition to avoid it _could_ have a _slim_ possibility of yielding a small performance improvement. (Assuming of course that `!=` is significantly faster.) – Disillusioned Mar 31 '16 at 16:10

3 Answers3

2

There can not be consensus on such small part of code. There are multiple things that affect the performance heavily, and these things differ based on the context of the code that surrounds this if statement.

For example, if you write:

const foo == 0;
if(foo != 0)
{
bar += foo;
}

The if statement will not even be in resulting binary, because compiler knows it will always be false.

Regarding the check for 0, if there is big chance for value to be 0, there is processor heuristic in place(called branch prediction), that automatically checks propability how many times the if statement suceeded in the past(when it is in while/for loop) and "predict" the result of statement.

This question shows the difference the branching might have on code performace really well.

Community
  • 1
  • 1
Tomáš Šíma
  • 834
  • 7
  • 26
  • 1
    That is a very silly if statement as you know that `const` variables to not change. – NathanOliver Mar 31 '16 at 15:52
  • Of course it is really extreme case, but I think it demonstrates what I am trying to say well. – Tomáš Šíma Mar 31 '16 at 15:53
  • 1
    I think the point is that the difference cannot be measured on C++ level. At least should one look at the compiled assembly code. – WhatsUp Mar 31 '16 at 15:53
  • You have got the point. Since the OP is asking such question, I thought the c++ demonstration what can affect the performance is more understandable. Feel free to edit though :) – Tomáš Šíma Mar 31 '16 at 15:56
-1

This is optimization is not really necessary. assembly

if(foo != 0) translates into a two assembly instruction

and bar += foo; translates into two also

So I would say, if we also add the small branching done by the if statement, I think that is better to just add foo to bar even if many times does not affect to the bar value.

Asier Sánchez Rodríguez
  • 406
  • 3
  • 11
-1

Ofcourse the checking more efficient. Assume 25% chance to be 0, so in 100times calling with full chance you are skipping to compile that line 25 times. Thus, your complexity is %25 less in best case.

Vurgun M
  • 97
  • 1
  • 5
  • 1
    checking cost instruction(s) so is it really more efficient? – NathanOliver Mar 31 '16 at 16:51
  • Is checking still more efficient if it causes a branch misprediction, followed by a pipeline flush? What if the comparison and branch instructions cause a critical piece of code to be slightly longer than the instruction cache, causing a cache miss on each iteration through the code? The only way to say for sure would be to measure the actual performance of the code, or to analyze the generated assembly with a very solid mental model of the CPU it will be executed on. – joelw Mar 31 '16 at 18:47