Optimisation : If-else, or just if?

Started by
18 comments, last by Zipster 19 years, 7 months ago
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).
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan
Advertisement
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...
Arguing on the internet is like running in the Special Olympics: Even if you win, you're still retarded.[How To Ask Questions|STL Programmer's Guide|Bjarne FAQ|C++ FAQ Lite|C++ Reference|MSDN]
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->Collided() ) {        return true;    }}
"Learn as though you would never be able to master it,
hold it as though you would be in fear of losing it" - Confucius
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.
"We should have a great fewer disputes in the world if words were taken for what they are, the signs of our ideas only, and not for things themselves." - John Locke
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.
GCC creates identical code for both of the snippets with all documented optimization settings. (-O0,-Os,-O1,-O2 and -O3)
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->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->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!
"In order to understand recursion, you must first understand recursion."
My website dedicated to sorting algorithms
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->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.
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.
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.

This topic is closed to new replies.

Advertisement