Sign in to follow this  

Optimisation : If-else, or just if?

This topic is 4857 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

This is an optimisation question, and I know that it's a totally useless optimisation - I'm just curious. Which is more efficient : if (enemy == null) return; enemy.getShot(this); or if (enemy == null) return; else enemy.getShot(this); Perhaps a modern compiler produces equivalent machine code anyway? Or is (jump to next line) equally efficient to (jump to line x, x = next)? Or could you really save a nanosecond by choosing one option? I'm dying to know!

Share this post


Link to post
Share on other sites
They should generate identical machine cose, since in both cases the if returns, and when the if is false it jumps around the 'return'.

If there is a speed difference, you _NEED_ to change compilers because your compiler has 'reverse optimization' or something where it makes the code worse.

Share this post


Link to post
Share on other sites
This is micro-optimisation, anyway so I wouldn't even bother...
[edit]
Sorry, missed that first line of yours [smile]
As the others said - it makes no difference.
[/edit]

Share this post


Link to post
Share on other sites
It really shouldn't make a difference, no matter what the compiler does. All the else statement does is introduce a jump label for the if-branch to jump over after it has been executed.


if statement is true then goto if_branch
goto else_branch;

if_branch:
execute if-branch
goto end_else

else_branch:
execute else-branch

end_else:
...


so essentially, all you do by omitting a (useless) else statement is getting rid of one goto and the subsequent else-branch part. You could see measurable results if you manage to get this into a very tight loop and fool the CPUs branch prediction. But this is highly unlikely since the goto inside the if-branch is non-conditional.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
you should in 99% of the cases never use an if in a time critical situation, so this should never bother you, if you end up with an if in an innerloop you are on deep water anyway, try rethink your algorithm.

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
you should in 99% of the cases never use an if in a time critical situation, so this should never bother you, if you end up with an if in an innerloop you are on deep water anyway, try rethink your algorithm.
While this might be true in low powered systems, on the PC this kind of thing is really no longer a rule. Just about every time critical system in a game NEEDs conditional brances to do its job. It is a good idea to limit them and keep them simple, but it is impossible to eliminate them in many situations.

Unless you're talking about realtime in a way entirely unrelated to game programming (as in 'realtime mission critical systems' whose failure could cost real lives), in which case it isn't really relevant.

Share this post


Link to post
Share on other sites
Quote:
Original post by Extrarius
If there is a speed difference, you _NEED_ to change compilers because your compiler has 'reverse optimization' or something where it makes the code worse.


"pessimization"

As in "Belated pessimization is the leaf of no good." (a cookie to whomever finds the source of the quote).

Share this post


Link to post
Share on other sites
Quote:
Original post by Fruny
As in "Belated pessimization is the leaf of no good." (a cookie to whomever finds the source of the quote).

OT, but I couldn't resist... Len Lattanzi - Google made it easy...

Share this post


Link to post
Share on other sites
Quote:
you should in 99% of the cases never use an if in a time critical situation, so this should never bother you, if you end up with an if in an innerloop you are on deep water anyway, try rethink your algorithm.


That doesn't make any sense. What should be used instead, then?

Sometimes you *have* to check to see if something happens or not, eg,


for( int i = 0; i < objects.size(); i++ ) {
if( objects[i]->Collided() ) {
return true;
}
}

Share this post


Link to post
Share on other sites
Bitwise operations, and other various tricks, probably. I'd rather just use obvious conditional statements, and only fiddle with tricks and such later, as needed. Unless something was really easy and obvious, and obviously beneficial.

Share this post


Link to post
Share on other sites
If this is java (which I assume it is), then you might be better off with a NullEnemy, then you won't have to make the comparison at all. Of course you'll then always have a virtual function being called instead, which will probably have more overhead. Or you could insist that you are only passed valid objects, but I'm not sure how to do that in java. In C++ references have to be valid so you would use them.

If this were C++ I'd now go into detail about replacing pointers with references, but you can probably search for the numerous threads about null where I've suggested that before, if you're interested.

Share this post


Link to post
Share on other sites
Quote:
Original post by red_sodium
Quote:
you should in 99% of the cases never use an if in a time critical situation, so this should never bother you, if you end up with an if in an innerloop you are on deep water anyway, try rethink your algorithm.


That doesn't make any sense. What should be used instead, then?

Sometimes you *have* to check to see if something happens or not, eg,


for( int i = 0; i < objects.size(); i++ ) {
if( objects[i]->Collided() ) {
return true;
}
}
Not that I'm actually sugesting you do this but...

bool result = false;
for( int i = 0; i < objects.size(); i++ ) {
result |= objects[i]->Collided();
}
return result;
}
Of course this isn't the innermost loop in this case. It's probably in Collided().

Min/max clipping without if's:
inline int clipMinMax(int value, const int minVal = 0, const int maxVal = 255) {
int bLess = value < minVal, bGreater = value > maxVal;
return (maxVal & (-(int)bGreater)) | (
((minVal & (-(int)bLess)) | (value & (-(int)!bLess))
) & (-(int)!bGreater));
}
You get the idea. Just please don't do this kind of stuff until you KNOW it's going to make the biggest speed increase!

Share this post


Link to post
Share on other sites
Quote:
Original post by iMalc
Not that I'm actually sugesting you do this but...

bool result = false;
for( int i = 0; i < objects.size(); i++ ) {
result |= objects[i]->Collided();
}
return result;
}
Of course this isn't the innermost loop in this case. It's probably in Collided().

Also, this is semantically different from the original code! The original bailed out after the first collision while yours goes through all objects and calls the Collided() method. In a sparse system this might not be a big difference, but if collisions are likely (or the Collided() method is expensive), this migt be a big difference.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by Anonymous Poster
you should in 99% of the cases never use an if in a time critical situation, so this should never bother you, if you end up with an if in an innerloop you are on deep water anyway, try rethink your algorithm.


what i mean is that if you are trying to save a cycle you are probably in a time critical loop and thus it's better to rethink the algorithm to not use if's in the most time critical loop, i mean, if this wasn't time critical there would be no need for saving that cycle.

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
what i mean is that if you are trying to save a cycle you are probably in a time critical loop and thus it's better to rethink the algorithm to not use if's in the most time critical loop, i mean, if this wasn't time critical there would be no need for saving that cycle.

Or, you're simply falling victim to premature optimization as so many do.

Share this post


Link to post
Share on other sites

This topic is 4857 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this