Question:
Java: IF-ELSE vs switch/case statement for efficiency?
Pirune Four
2010-10-11 09:02:48 UTC
Forgetting about readability or being concise, is it more efficient to have an IF-ELSE statement or a switch/case statement? Is there is certain number of "cases" where one becomes more efficient than the other? Thanks
Seven answers:
green meklar
2010-10-11 13:20:57 UTC
It depends on the situation. So long as the switch statement is taking in values in a fairly small range, it is more time-efficient. That is to say, something like this:



switch(x)

{

case 3:

//whatever

break;

case 4:

//whatever

break;

case 5:

//whatever

break;

case 7:

//whatever

break;

}



is a good switch statement. So long as you are using most of the values within the possible range of values, switch statements are more efficient than if else statements and become even better with additional cases. However, if there are relatively few values over a very large and arbitrary range, then although the switch statement still runs faster, it takes up a ridiculous amount of memory. For instance, something like this:



switch(x)

{

case 3:

//whatever

break;

case 157:

//whatever

break;

case 994589:

//whatever

break;

case 278043814:

//whatever

break;

}



is a bad switch statement. In fact, most compilers will probably automatically convert inefficient switch statements like this into if else statements internally, giving away the time advantage in return for making the program far more compact.
granelli
2016-11-08 06:07:22 UTC
Switch Vs If Else
Nik
2010-10-11 09:37:26 UTC
Modern compilers will choose the best compatible construct to replace the construct you have written in your code if necessary. For example, I'm pretty sure most Java compilers will emit an if...else bytecode structure that is equivalent to the switch statement in your Java code.



Some compilers are even clever enough to perform simple refactoring and optimisation of boolean expressions, completely changing the structure of if...else statements while retaining the original semantics and flow of control.



Anyone with a formal education in compiler theory (such as the compiler dev teams at Sun and Microsoft) will consider an if...else statement to be a form of switch, rather than the other way around, since even a simple if (with no else) is usually modelled as a switch statement by compilers. This is because the compiler can apply optimisations to switch constructs easier than can apply them to if...else constructs.



For example, the following two sets of code will result in similar bytecode with only trivial differences that don't warrant mentioning:



switch (condition)

{

case true:

// Do positive condition stuff

break;

default:

// Do negative condition stuff

break;

}



...and...



if (condition)

{

// Do positive condition stuff

}

else

{

// Do negative condition stuff

}



In most languages there are grammatical differences between the two constructs, such as scope rules preventing variables from being declared directly in a case block (most languages require that you declare a new scope first), but there are no semantic differences.



So, in answer, there's no real advantage of using one over the other, except in terms of readability.



The exception is when you start missing out break statements, and allowing control to drop through from one case to the next; in this situation the compiler has to generate additional bytecode to control which case blocks should be executed, resulting in a larger bytecode image and slower execution - not to mention the messy, unreadable and unmaintainable source code ;-)



If you are really interested to see the exact difference, you will need to inspect the bytecode your particular compiler emits for equivalent switch and if...else constructs.
Pfo
2010-10-11 10:32:43 UTC
I used to think that switch was just syntax for a series of if-else cases.



Boy was I wrong.



It turns out that many compilers make some very convoluted code for switch statements whose performance is O (log(n)) with many statements, whereas a series of if-else statement's performance is O(n). Switch is often faster if your compiler optimizes the code, if not, then their is no difference. Any switch statement with more than 4 cases is going to be faster than a series of if-else in optimizing compilers.
BobberKnob
2010-10-11 12:55:53 UTC
It depends on your compiler.

Usually,When you have if/if else statements, the program will check each condition as it goes through.



A switch statement, the program only "Falls through" to the correct case, and then "breaks". Virtually all in the same operation.
deonejuan
2010-10-11 09:36:03 UTC
switch{

case:

default:}

has always been regarded as less efficient in execution time. Bear in mind when you code

for( int i = 0; i< 10; i++)

System.out.printlnI("Howdy doody");



That puts 10 System.out.println( string ) on the heap, not the for-loop statement itself. Likewise with the switch( choice ), the heap gets 1 more if( statement) than an if-else tree would require. And every time you send the 'choice' value, the logic tree is reconstructed on the heap.



But, coding is for simplicity of description. We use switch( ) if it makes the code cleaner and easier to to determine the logic.
Darnental
2010-10-11 09:17:09 UTC
No difference. As far as I know, they have the exact same underlying principles. So if they both have the exact same functionality, and the comparisons in the if statement are never made more than necessary, it's exactly the same.



For instance:



if(x == 1){

System.out.println("one");

}

else if(x == 2){

System.out.println("two");

}

else if(x == 3){

System.out.println("three");

}



is exactly the same to:



switch(x){

case 1:

System.out.println("one");

break;

case 2:

System.out.println("two");

break;

case 3:

System.out.println("three");

break;

}



but make sure you have the "else" statements there, otherwise "if" becomes less efficient since it needs to check "x" two extra times.


This content was originally posted on Y! Answers, a Q&A website that shut down in 2021.
Loading...