Comments on: If-else vs switch – Which is better? http://www.ashishpaliwal.com/blog/2009/08/if-else-vs-switch-%e2%80%93-which-is-better/ From Programmer, For Programmers Tue, 17 Aug 2010 12:04:21 +0000 hourly 1 http://wordpress.org/?v=3.0 By: AKriauciunas http://www.ashishpaliwal.com/blog/2009/08/if-else-vs-switch-%e2%80%93-which-is-better/comment-page-1/#comment-14211 AKriauciunas Tue, 25 May 2010 21:09:04 +0000 http://www.ashishpaliwal.com/blog/?p=303#comment-14211 I didn't see anyone mention the underlying issue when dealing with compiled code - whenever you don't know for sure what the next statement is going to be (at the machine code level), the compiler will have to insert a few (typically 2-3) NOPs to flush the pipeline. I believe the systems I worked on (Ti DSP processors) used 2-3 NOPs to do this. So, all things being equal, every time you evaluate an if/else you have a few wasted instruction cycles. The switch absorbs the overhead once when it looks up the jump offset in the jump table. So, the real question is at which point does the variable overhead (flushing the pipeline every time you see an if statement) outweigh the slightly higher fixed overhead (computing the jump offset). If your algorithm is on the critical path in a real-time environment, these are definitely important issues. I didn’t see anyone mention the underlying issue when dealing with compiled code – whenever you don’t know for sure what the next statement is going to be (at the machine code level), the compiler will have to insert a few (typically 2-3) NOPs to flush the pipeline. I believe the systems I worked on (Ti DSP processors) used 2-3 NOPs to do this. So, all things being equal, every time you evaluate an if/else you have a few wasted instruction cycles. The switch absorbs the overhead once when it looks up the jump offset in the jump table. So, the real question is at which point does the variable overhead (flushing the pipeline every time you see an if statement) outweigh the slightly higher fixed overhead (computing the jump offset). If your algorithm is on the critical path in a real-time environment, these are definitely important issues.

]]> By: ksongking http://www.ashishpaliwal.com/blog/2009/08/if-else-vs-switch-%e2%80%93-which-is-better/comment-page-1/#comment-6673 ksongking Tue, 18 Aug 2009 02:21:03 +0000 http://www.ashishpaliwal.com/blog/?p=303#comment-6673 Since many expects are here. I did try to benchmark in between if/else and switch case before. I agreed on switch case is faster than the if/else case, but normally the test is taking the avarage measurement for both statements to get matched. Last time when i did my test, i found another finding, i was using Bios/DSP and use the ADI provided compiler to benchmark the cycle counts for both statements, i found that, the switch statement is faster than the if/else statement. But, the time to match the first case in switch is the same with the time to match the last case, or the default case of the switch, so, regardless which case i matched in the switch statement, it will take the constant cycle times to run the who switch statement, and the cycle time is increasing if there are more case added in, my finding is, for switch statement, the time spent to match any cases is the same, there has no advantage even the first case is matched. Compare to the if/else statement, the last matching condition always take much than the switch, but if the condition always hit the first or second condition, then the cycle time reduced very much, so normally when using the if/else statement, we will prioritize the most likely happen case on top, this can really speed up the comparison compare to switch case since no matter which case it will be matched, the time taken will be constantly long, and it consume more MIPS when more cases added in. Please verify my finding. Since many expects are here. I did try to benchmark in between if/else and switch case before. I agreed on switch case is faster than the if/else case, but normally the test is taking the avarage measurement for both statements to get matched. Last time when i did my test, i found another finding, i was using Bios/DSP and use the ADI provided compiler to benchmark the cycle counts for both statements, i found that, the switch statement is faster than the if/else statement. But, the time to match the first case in switch is the same with the time to match the last case, or the default case of the switch, so, regardless which case i matched in the switch statement, it will take the constant cycle times to run the who switch statement, and the cycle time is increasing if there are more case added in, my finding is, for switch statement, the time spent to match any cases is the same, there has no advantage even the first case is matched. Compare to the if/else statement, the last matching condition always take much than the switch, but if the condition always hit the first or second condition, then the cycle time reduced very much, so normally when using the if/else statement, we will prioritize the most likely happen case on top, this can really speed up the comparison compare to switch case since no matter which case it will be matched, the time taken will be constantly long, and it consume more MIPS when more cases added in. Please verify my finding.

]]> By: Ray http://www.ashishpaliwal.com/blog/2009/08/if-else-vs-switch-%e2%80%93-which-is-better/comment-page-1/#comment-6365 Ray Wed, 05 Aug 2009 15:47:07 +0000 http://www.ashishpaliwal.com/blog/?p=303#comment-6365 The biggest benefit I tell junior programmers, in support of switch statement, is IDE support. If you add an item to an Enumeration, many IDEs will warn you that it is not being used in your switch statement. So the IDE is helping you ensure that your forking code is correct. With if/else, you have to search through the code and hope you don't make a mistake. So to me, this is a readability and maintenance issue. The biggest benefit I tell junior programmers, in support of switch statement, is IDE support. If you add an item to an Enumeration, many IDEs will warn you that it is not being used in your switch statement. So the IDE is helping you ensure that your forking code is correct. With if/else, you have to search through the code and hope you don’t make a mistake.

So to me, this is a readability and maintenance issue.

]]> By: ashish http://www.ashishpaliwal.com/blog/2009/08/if-else-vs-switch-%e2%80%93-which-is-better/comment-page-1/#comment-6325 ashish Tue, 04 Aug 2009 14:52:53 +0000 http://www.ashishpaliwal.com/blog/?p=303#comment-6325 Well Sysouts are present in both cases and its comparative. Since conditions are same, both emit output to console. So this was fine in my case. Not sure what's next, right now hacking Apache Vysper code. Well Sysouts are present in both cases and its comparative. Since conditions are same, both emit output to console. So this was fine in my case.
Not sure what’s next, right now hacking Apache Vysper code.

]]> By: ashish http://www.ashishpaliwal.com/blog/2009/08/if-else-vs-switch-%e2%80%93-which-is-better/comment-page-1/#comment-6324 ashish Tue, 04 Aug 2009 14:49:06 +0000 http://www.ashishpaliwal.com/blog/?p=303#comment-6324 Thanks Kirk! My simple objective was to evaluate my review comment "Which is better" in general context. Console IO is present for both. So the conditions are similar for both cases. Thanks Kirk! My simple objective was to evaluate my review comment “Which is better” in general context. Console IO is present for both. So the conditions are similar for both cases.

]]> By: ppow http://www.ashishpaliwal.com/blog/2009/08/if-else-vs-switch-%e2%80%93-which-is-better/comment-page-1/#comment-6317 ppow Tue, 04 Aug 2009 10:52:29 +0000 http://www.ashishpaliwal.com/blog/?p=303#comment-6317 Why are you doing the benchmarking with System.out.printlns?? This is strongly affecting the results you are getting as this is a really time consuming operation. Maybe try to replace it with any other non-trivial opp (so that the compiler does not optimize your code and skip if-else or switch) or try to subtracts from the result the costs of System.out.println? BTW: this is a really interesting topic, let me know about what you'll do next :) Why are you doing the benchmarking with System.out.printlns?? This is strongly affecting the results you are getting as this is a really time consuming operation. Maybe try to replace it with any other non-trivial opp (so that the compiler does not optimize your code and skip if-else or switch) or try to subtracts from the result the costs of System.out.println?

BTW: this is a really interesting topic, let me know about what you’ll do next :)

]]> By: scot http://www.ashishpaliwal.com/blog/2009/08/if-else-vs-switch-%e2%80%93-which-is-better/comment-page-1/#comment-6311 scot Tue, 04 Aug 2009 06:13:22 +0000 http://www.ashishpaliwal.com/blog/?p=303#comment-6311 First, microbenchmarks are a waste of time. Second, as Shaun says above, using either switch or if-else especially for more than the most trivial of cases is a very good indicator your code is in poor shape and requires redesigning. There is no "better" in this circumstance. Either way it is a pointer to a failure to apply the many well-known and well-proven techniques of object orientated design. First, microbenchmarks are a waste of time.

Second, as Shaun says above, using either switch or if-else especially for more than the most trivial of cases is a very good indicator your code is in poor shape and requires redesigning. There is no “better” in this circumstance. Either way it is a pointer to a failure to apply the many well-known and well-proven techniques of object orientated design.

]]> By: kirk http://www.ashishpaliwal.com/blog/2009/08/if-else-vs-switch-%e2%80%93-which-is-better/comment-page-1/#comment-6310 kirk Tue, 04 Aug 2009 05:49:31 +0000 http://www.ashishpaliwal.com/blog/?p=303#comment-6310 I forgot to mention the timings are well within the range that you are measuring randomness. Any benchmark needs to be run for a significant period of time to dampen out the resolution of the clock and the cost of getting that measurement. I forgot to mention the timings are well within the range that you are measuring randomness. Any benchmark needs to be run for a significant period of time to dampen out the resolution of the clock and the cost of getting that measurement.

]]> By: kirk http://www.ashishpaliwal.com/blog/2009/08/if-else-vs-switch-%e2%80%93-which-is-better/comment-page-1/#comment-6309 kirk Tue, 04 Aug 2009 05:48:01 +0000 http://www.ashishpaliwal.com/blog/?p=303#comment-6309 This bench is busted. First, get rid of the writing to console. It's activity will completely dominate the profile. Secondly, I'd take a look at the byte code. I think you'll find that sparse switch and if-else get about the same byte code so there should be no difference. The range will be a calculated goto and so the result of the bench will be completely dependent on the ordering of the data. There is no such thing as a simple microbenchmark. Regards, Kirk This bench is busted. First, get rid of the writing to console. It’s activity will completely dominate the profile. Secondly, I’d take a look at the byte code. I think you’ll find that sparse switch and if-else get about the same byte code so there should be no difference. The range will be a calculated goto and so the result of the bench will be completely dependent on the ordering of the data.

There is no such thing as a simple microbenchmark.

Regards,
Kirk

]]> By: ashish http://www.ashishpaliwal.com/blog/2009/08/if-else-vs-switch-%e2%80%93-which-is-better/comment-page-1/#comment-6304 ashish Tue, 04 Aug 2009 01:08:10 +0000 http://www.ashishpaliwal.com/blog/?p=303#comment-6304 Thanks Shaun for the pointer. However, my objective here was very simple to see which is better. Most cases that I encounter, there are typically 5-8 conditions. Well, I just wanted to check that what I understand is really true under what circumstances. Thanks Shaun for the pointer. However, my objective here was very simple to see which is better. Most cases that I encounter, there are typically 5-8 conditions. Well, I just wanted to check that what I understand is really true under what circumstances.

]]>