Advertisement

Which executes faster: if's or case's?

Started by December 10, 2002 07:55 PM
8 comments, last by OOBradm 21 years, 11 months ago
This question just popped in my head as I was working on a project... which runs ''faster''? Im sure it has to do with the length of the statement. My guess is that if''s are faster for short statements and switches are better for longer statements. Anyone know for a fact which is faster?
When they''re compiled they are just asembly language jumps. so I''ll assume that they end up being the same. But, if one was faster than the other... I would think that it would be ifs. But I''m just guessing.
Advertisement
I have a much better question: Which one fits the task you are trying to do best? Which one gives the most elegant and readable code?


For those who believe in God, most of the big questions are answered. But for those of us who can''t readily accept the God formula, the big answers don''t remain stone- written. We adjust to new conditions and discoveries. We are pliable. Love need not be a command or faith a dictum. I am my own God. We are here to unlearn the teachings of the church, state, and our educational system. We are here to drink beer. We are here to kill war. We are here to laugh at the odds and live our lives so well that Death will tremble to take us -- Charles Bukowski
--AnkhSVN - A Visual Studio .NET Addin for the Subversion version control system.[Project site] [IRC channel] [Blog]
personally i use if but they do all the same thing! You stop about which one better suits you.

shuv-it

[edited by - craphead on December 10, 2002 9:18:18 PM]
50/50 Robotics and Software
First of all:

For the code you are doing now, and likely for all the code you will ever do, it doesn''t matter squat which is faster. You should be focusing more on making your code work (which includes making it readable, since it will take you forever to debug/enhance obfuscated code) and less on being concerned over micro-optimization. If you are really concerned about how fast your game is then look at the algorithms you are using, and how you are putting your graphics on the screen.

And now to answer your question.
Short answer:
For a comparision, IF is faster (it''s a conditional jump in assembly). For branching to more than 2 items based on the value of a variable, use a case statement, it generated a jump table (and it''s easier to read, which codewise is a Good Thing).

Long answer:
It all depends on what your data is. If your data is almost always the same value it could well be *faster* (but not always better) to code it as several nested IFs, so that you can take advantage of branch prediction. If you don''t fully understand things like branch prediction, cache, stalling and assembly in general then I would advise against trying this at all (you''ll probably make it worse).
Hey, thanks for the prompt replies. I wasnt really concerned about the speed, it was just a question that popped into my head while I was coding. Seeing as how you guys replied, it is more important to make the code readable than to worry about speed. As of right now I know very little about game design. Ive been taking c++ for a little over a year now and am learning MFC. Ive heard that MFC is basically useless to learn? how much truth is there to that?
Advertisement
http://www.gamedev.net/community/forums/topic.asp?topic_id=127392
Ok, a case statement will end up being just as fast as a bunch of if statements UNLESS you have sequential cases such as...

switch(x)
{
case 1:
//add code here
break;
case 2:
//add code here
break;
case 3:
//add code here
break;
}

That switch statement will make a jump table, which is faster, since the numbers are sequential, I could have also used the numbers 3,4,and 5. or any sequential cases. If the cases are not sequential though, your compiler is simply going to treat your code as a bunch of if's similar to the code below.

if ( x == 11 )
//add code

if ( x == 28 )
//add code

if ( x == 14 )
//add code

If these numbers were sequential though such as 11, 12, and 13 I assume that some compilers may make a jump table for this code as well, making them just as fast as sequential cases, but I'm not sure if many or any compilers would actually make that optimization.

~Vendayan

[edited by - Vendayan on December 11, 2002 4:06:50 AM]
"Never have a battle of wits with an unarmed man. He will surely attempt to disarm you as well"~Vendayan
Just a side note :
You cannot use const values with case (I tried it and the compiler just say "Error etc..."). You have to use if-else if-else.


  //const int GOOD = 0 ;const int AVERAGE = 1 ;//...etc...switch(value){   case GOOD: //error !   //no more to say...}  


By the way, which is better to use for such case : const values or enum ?
I precise that I am more used to Java, thus the use of const I made, but I feel like enum could be more appropriate, so where is the truth ?

Ah I just remember a reason why I feel I should stick to const : the const are defined in a class and represents a state of an instance. I will extend this base class and the derivated class will have new values available to describe the state.

To sum up :


  class Variant{    public:    static const int BOOL ;    static const int CHAR ;    static const int STRING ;    //etc...    GetState() {return mState;}    protected:    int mState ;    //other stuff...};//The following is what I plan to writeclass UnicodeVariant : public Variant{    static const int WCHAR ;    static const int WSTRING ;    //other stuff...};typedef Variant MyVariantType ; // for now I use Variant//But in future applications, I might use UnicodeVariant instead of Variant (with no switch back to Variant)//typedef UnicodeVariant MyVariantType  



----
David Sporn AKA Sporniket
quote: Original post by davidsporn
You cannot use const values with case (I tried it and the compiler just say "Error etc..."). You have to use if-else if-else.


There must have been another reason why the compiler complained. In fact, ''switch'' requires constant values!


<a href="http://www.purplenose.com>purplenose.com

This topic is closed to new replies.

Advertisement