Comments on: Optimizing Switch-Case Statements In C For Speed http://www.safercode.com/blog/2008/10/28/optimizing-switch-case-statements-in-c-for-speed.html Making Your Code Faster, Stronger, Safer… Tue, 31 Aug 2010 16:47:37 +0000 http://wordpress.org/?v=2.9.1 hourly 1 By: Greg Smith http://www.safercode.com/blog/2008/10/28/optimizing-switch-case-statements-in-c-for-speed.html#comment-3515 Greg Smith Wed, 02 Jun 2010 21:37:04 +0000 http://www.safercode.com/blog/?p=17#comment-3515 Will just add this: In cases where compilers do not generate jump tables (due to cases too few or too sparse) most compilers I've looked into will not generate a one-by-one search, instead they will start by comparing to a number numerically near the middle of the list, and branch differently for greater or less; basically they build a fixed 'binary tree' search, so the number of compare to find the right case will be O(log(n)). In that case it won't matter what order you put them in. @Shantanu "gcc 3.x series can’t even create a good jump table for small switch case statement". How do you know the jump table is going to be better? if 5 or 6 cases are handled by a few compares, and you have branch prediction hardware in the processor, that could easily be better than the jump table (which always takes an unpredictable branch, plus a data-dependent memory read). Look at this way, if they create one for a big list, and not for a small list, that was a deliberate decision. Will just add this: In cases where compilers do not generate jump tables (due to cases too few or too sparse) most compilers I’ve looked into will not generate a one-by-one search, instead they will start by comparing to a number numerically near the middle of the list, and branch differently for greater or less; basically they build a fixed ‘binary tree’ search, so the number of compare to find the right case will be O(log(n)). In that case it won’t matter what order you put them in.

@Shantanu “gcc 3.x series can’t even create a good jump table for small switch case statement”. How do you know the jump table is going to be better? if 5 or 6 cases are handled by a few compares, and you have branch prediction hardware in the processor, that could easily be better than the jump table (which always takes an unpredictable branch, plus a data-dependent memory read). Look at this way, if they create one for a big list, and not for a small list, that was a deliberate decision.

]]> By: Zombie No. 5 http://www.safercode.com/blog/2008/10/28/optimizing-switch-case-statements-in-c-for-speed.html#comment-670 Zombie No. 5 Sun, 05 Apr 2009 17:32:26 +0000 http://www.safercode.com/blog/?p=17#comment-670 Rather than optimizing for speed, you should consider optimizing for safety and correctness. Whenever it makes sense, for example, when implementing a finite-state machine consider enumerators instead of integers. A good compiler like GCC will warn you about unhandled cases. Of course, that means you have to omit the "default:" label. You should still catch unhandled values like in the example below: enum my_enum { a, b, c }; int function(enum my_enum value) { switch (value) { case a: return ...; case b: return ...; case c: return ...; } /* handle unexpected case */ } Of course you can also use goto or a flag, if use of return as above isn't suitable. By the way, a compiler can only generate a jump table if it can deduce that the switch parameter or the label values are from a limited range. A jump-table with UINT_MAX entries would be hardly efficient or desirable. Rather than optimizing for speed, you should consider optimizing for safety and correctness. Whenever it makes sense, for example, when implementing a finite-state machine consider enumerators instead of integers. A good compiler like GCC will warn you about unhandled cases. Of course, that means you have to omit the “default:” label. You should still catch unhandled values like in the example below:

enum my_enum { a, b, c };

int
function(enum my_enum value)
{
switch (value) {
case a: return …;
case b: return …;
case c: return …;
}
/* handle unexpected case */
}

Of course you can also use goto or a flag, if use of return as above isn’t suitable.

By the way, a compiler can only generate a jump table if it can deduce that the switch parameter or the label values are from a limited range. A jump-table with UINT_MAX entries would be hardly efficient or desirable.

]]> By: compiler http://www.safercode.com/blog/2008/10/28/optimizing-switch-case-statements-in-c-for-speed.html#comment-100 compiler Fri, 06 Feb 2009 06:23:03 +0000 http://www.safercode.com/blog/?p=17#comment-100 I also agree that the micro optimization is not always useful. There are lots of code patterns which can be observe by a compiler and can be optimized by compiler. But compilers do not implement all of these patterns and only observe most common code patterns. So it is batter to write the simple code without micro-optimization (which may be optimized for one processor but not for other), and let compiler do the optimization. I also agree that the micro optimization is not always useful. There are lots of code patterns which can be observe by a compiler and can be optimized by compiler. But compilers do not implement all of these patterns and only observe most common code patterns. So it is batter to write the simple code without micro-optimization (which may be optimized for one processor but not for other), and let compiler do the optimization.

]]> By: David F. Skoll http://www.safercode.com/blog/2008/10/28/optimizing-switch-case-statements-in-c-for-speed.html#comment-91 David F. Skoll Mon, 02 Feb 2009 11:48:53 +0000 http://www.safercode.com/blog/?p=17#comment-91 What a waste of time. Micro-optimizations are almost never helpful. Unless you know for sure the assembly code produced by the compiler, you're just guessing. And even if you do examine the generated code... congratulations! You've wasted time micro-optimizing for *one* compiler on *one* processor architecture. What a waste of time. Micro-optimizations are almost never helpful. Unless you know for sure the assembly code produced by the compiler, you’re just guessing. And even if you do examine the generated code… congratulations! You’ve wasted time micro-optimizing for *one* compiler on *one* processor architecture.

]]> By: Shantanu Goel http://www.safercode.com/blog/2008/10/28/optimizing-switch-case-statements-in-c-for-speed.html#comment-90 Shantanu Goel Mon, 02 Feb 2009 10:39:59 +0000 http://www.safercode.com/blog/?p=17#comment-90 @Ron: Thanks. You are absolutely correct in your observation that other issues/optimizations are worth more time than switch-case optimization. However, we've started this blog to capture as much as we can about these topics, however obscure it might be. So, you will see us covering this as well as all other aspects of optimization, security, etc that make up the base for a solid code. And I hope that readers like you, daniel, dummy, andre and others will keep us on our toes and correct us wherever we deviate from the right path. Thanks once again. :) @Ron: Thanks. You are absolutely correct in your observation that other issues/optimizations are worth more time than switch-case optimization. However, we’ve started this blog to capture as much as we can about these topics, however obscure it might be. So, you will see us covering this as well as all other aspects of optimization, security, etc that make up the base for a solid code. And I hope that readers like you, daniel, dummy, andre and others will keep us on our toes and correct us wherever we deviate from the right path. Thanks once again. :)

]]> By: Ron http://www.safercode.com/blog/2008/10/28/optimizing-switch-case-statements-in-c-for-speed.html#comment-89 Ron Mon, 02 Feb 2009 07:36:02 +0000 http://www.safercode.com/blog/?p=17#comment-89 Well, given all the other common errors that are made, this case optimizing is something that is needed only in very specific cases. You normally would only need this if you want to optimize a CPU intensive task where the case statement is the bottleneck. Seems pretty far-stretched to me. In 20 years of systems programming (in C) I don't remember ever actually needing to optimize a case statement. Also, if ever you encounter such a situation anyway, then #2 might prove the most useful advice. Well,

given all the other common errors that are made, this case optimizing is something that is needed only in very specific cases. You normally would only need this if you want to optimize a CPU intensive task where the case statement is the bottleneck. Seems pretty far-stretched to me.
In 20 years of systems programming (in C) I don’t remember ever actually needing to optimize a case statement.
Also, if ever you encounter such a situation anyway, then #2 might prove the most useful advice.

]]> By: Shantanu Goel http://www.safercode.com/blog/2008/10/28/optimizing-switch-case-statements-in-c-for-speed.html#comment-88 Shantanu Goel Mon, 02 Feb 2009 06:11:45 +0000 http://www.safercode.com/blog/?p=17#comment-88 @daniel: Your assumption that a modern compiler will always generate the jump-table isn't correct. Just write some code according to the limitations I've mentioned and assemble it to see the same. A compiler can goof up as well if not given enough pointers. Heck, gcc 3.x series can't even create a good jump table for small switch case statements, leave apart the rest. Optimization of code is still a very relevant topic, especially if you are writing code for embedded devices. Moreover, not all compilers are good at optimization. If you have noticed, there are thousands of compilers out there in the market, many of which need to be used even if they are not that good at optimization. @daniel: Your assumption that a modern compiler will always generate the jump-table isn’t correct. Just write some code according to the limitations I’ve mentioned and assemble it to see the same. A compiler can goof up as well if not given enough pointers. Heck, gcc 3.x series can’t even create a good jump table for small switch case statements, leave apart the rest. Optimization of code is still a very relevant topic, especially if you are writing code for embedded devices. Moreover, not all compilers are good at optimization. If you have noticed, there are thousands of compilers out there in the market, many of which need to be used even if they are not that good at optimization.

]]> By: daniel http://www.safercode.com/blog/2008/10/28/optimizing-switch-case-statements-in-c-for-speed.html#comment-87 daniel Mon, 02 Feb 2009 05:25:56 +0000 http://www.safercode.com/blog/?p=17#comment-87 1. actually, most modern/decent compilers will generate the "jump-table". this renders "optimization technique 1" irrelevant. 2. "optimization technique 2" is also about weak (realy non-optimizing compilers) which fail to generate the jump-table. so, given the fact that the array is calculated by the compiler at compile time, then, of course, like any array, has a O(1), this "optimization technique" is also irrelevant. 3. "optimization technique 3" is also a patch for poorly implemented compilers. in almost 40 years of c/c++, i've never seen something so weird. besides, the whole thing (the whole idea of explicitly "optimizing" your code instead of using a decent compiler) is in lala land... (sounds like the late 60s, maybe early 70s). like the author said "this was it for today". quick reminder, we're in 2009... just in case some of us haven't noticed... :-) regards, d 1. actually, most modern/decent compilers will generate the “jump-table”. this renders “optimization technique 1″ irrelevant.

2. “optimization technique 2″ is also about weak (realy non-optimizing compilers) which fail to generate the jump-table. so, given the fact that the array is calculated by the compiler at compile time, then, of course, like any array, has a O(1), this “optimization technique” is also irrelevant.

3. “optimization technique 3″ is also a patch for poorly implemented compilers. in almost 40 years of c/c++, i’ve never seen something so weird.

besides, the whole thing (the whole idea of explicitly “optimizing” your code instead of using a decent compiler) is in lala land… (sounds like the late 60s, maybe early 70s).

like the author said “this was it for today”. quick reminder, we’re in 2009… just in case some of us haven’t noticed… :-)

regards,
d

]]> By: Shantanu Goel http://www.safercode.com/blog/2008/10/28/optimizing-switch-case-statements-in-c-for-speed.html#comment-86 Shantanu Goel Mon, 02 Feb 2009 05:24:03 +0000 http://www.safercode.com/blog/?p=17#comment-86 @Dummy00001: The lookup table is indeed a good option. Thanks for reminding us. @Dummy00001: The lookup table is indeed a good option. Thanks for reminding us.

]]> By: Shantanu Goel http://www.safercode.com/blog/2008/10/28/optimizing-switch-case-statements-in-c-for-speed.html#comment-85 Shantanu Goel Mon, 02 Feb 2009 05:22:59 +0000 http://www.safercode.com/blog/?p=17#comment-85 @Andre Goddard Rosa: Yes, Duff's device discussion is in the offing but in another context (loop unrolling) which is being taken care of in the latest series. Check out our latest post from Jan 27th. :) @Andre Goddard Rosa: Yes, Duff’s device discussion is in the offing but in another context (loop unrolling) which is being taken care of in the latest series. Check out our latest post from Jan 27th. :)

]]>