You’re looking at unoptimized code, so studying it for performance isn’t very meaningful. If you look at optimized code for your examples, you’ll find that it doesn’t do the comparisons at all! The optimizer notices that the switch variable
sc always has the value
1, so it removes the unreachable
The optimizer also sees that the variable
a isn’t used after it’s assigned, so it removes the code in
case 1 as well, leaving
main() an empty function. And it removes the function prolog/epilog that manipulates
rbp since that register is unused.
So the optimized code ends up the same for either version of your
main: xor eax, eax ret
In short, for the code in the question, it doesn’t matter which order you put the
case statements, because none of that code will be generated at all.
case order matter in a more real-life example where the code actually is generated and used? Probably not. Note that even in your unoptimized generated code, both versions test for the two
case values in numeric order, checking first for
1 and then for
2, regardless of the order in the source code. Clearly the compiler is doing some sorting even in the unoptimized code.
Be sure to note Glenn and Lundin’s comments: the order of the
case sections is not the only change between your two examples, the actual code is different too. In one of them, the case values match the values set into
a, but not so in the other.
Compilers use various strategies for
case statements depending on the actual values used. They may use a series of comparisons as in these examples, or perhaps a jump table. It can be interesting to study the generated code, but as always, if performance matters, watch your optimization settings and test it in a real-life situation.