Reputation: 1
I was wondering if the two different codes below performed better than the other. They do the same function. I would think that when implementing this code you would want the if statement to contain the argument that would occur more frequently.
Option #1
if(hoursWorked <= 40){
workedOvertime = 0;
}
else{
workedOvertime = 1;
}
Option #2
if(hoursWorked > 40){
workedOvertime = 1;
}
else{
workedOvertime = 0;
}
Upvotes: 0
Views: 132
Reputation: 29266
It is almost impossible to give an answer to this question as it will depend on the machine architecture, compiler, compiler options (e.g. optimisations) and a bunch of other things. For example one architecture I worked on we were told that conditionals using "not" were faster. I don't know if it's true, but if (hoursWorked <= 40)
would have been written if (!(hoursWorked > 40))
. I know: harder to read but that is what we were told to do!
It's likely that this is a case of Premature Optimization. i.e. Trying to fix this one tiny part of your code with the expectation of huge performance gains. That isn't going to happen.
For example, in 68K assembler, a "BEQ" (Branch on equal) takes 10 cycles if the condition is met and 8 or 12 if it isn't (depending on whether you are using bytes or words) - so that is 3 possible answers just for an "if" depending on types and which way the code goes. By comparison a single multiplication takes 70 cycles. If you get to IO then we're probable into thousands (if not more).
So unless you have a really good reason to care about stuff at this level then don't ! It's a waste of time. Write good readable code and then come back to this if and when you have a performance issue.
In reality all possible options are going to be very very close to each other and pale into insignificance compared to other things in your program. Unless you have a very specific case (e.g. a huge number of calls in a real time environment on an under powered embedded system) then it will make no difference.
Upvotes: 2
Reputation: 57922
On the Godbolt Compiler Explorer you can see what various compilers do with both versions, as well as KamilCuk's "option 3".
Guess what: with, for instance, the gcc compiler on x86-64 and optimization on, they all produce precisely the same code. So it makes no difference whatsoever.
(In particular, they all use a conditional set instruction that doesn't require a jump whether the condition is true or false.)
This is typical: modern compilers are smart enough to see that these are all equivalent, and to generate the best code no matter which way you wrote it. So it is a waste of time to think about such things. If one way seems to be clearer for someone reading the program, do it that way. If you don't think it makes any difference to a human, then just pick a way and move on.
If you have reason to believe that one case is more common than the other, you can use something like gcc's __builtin_expect
to hint this to the compiler. That way, if it is possible to optimize one branch to be faster than the other, the compiler will do so for the more common one. There can also be ways to use profiling to measure which branch is taken more often, and automatically inform the compiler of this. But the compiler normally won't try to draw such inferences just from your choice of which branch is the "then" and which is the "else".
However, in this case, using __builtin_expect
doesn't change anything, so both branches are already optimized as best the compiler knows how, and it doesn't know any way to make either one faster, even at the expense of making the other one slower.
Upvotes: 5