编译器可以对交换机进行几种优化。我不认为经常提到的“跳跃表”是非常有用的，因为它只在输入可以以某种方式被限制时才有效。

C“跳转表”的伪代码是这样的——注意，实际上编译器需要在表周围插入某种形式的if测试，以确保输入在表中是有效的。还要注意，它只在输入是连续数字的特定情况下才有效。

如果交换机中的分支数量非常大，编译器可以对交换机的值使用二进制搜索，这(在我看来)将是一个更有用的优化，因为它在某些场景中显著提高了性能，与交换机一样通用，并且不会导致更大的生成代码大小。但是要看到这一点，您的测试代码将需要更多的分支来查看任何差异。

回答您的具体问题:

Clang generates one that looks like this: test_switch(char): # @test_switch(char) movl %edi, %eax cmpl $19, %edi jbe .LBB0_1 retq .LBB0_1: jmpq *.LJTI0_0(,%rax,8) jmp void call<0u>() # TAILCALL jmp void call<1u>() # TAILCALL jmp void call<2u>() # TAILCALL jmp void call<3u>() # TAILCALL jmp void call<4u>() # TAILCALL jmp void call<5u>() # TAILCALL jmp void call<6u>() # TAILCALL jmp void call<7u>() # TAILCALL jmp void call<8u>() # TAILCALL jmp void call<9u>() # TAILCALL jmp void call<10u>() # TAILCALL jmp void call<11u>() # TAILCALL jmp void call<12u>() # TAILCALL jmp void call<13u>() # TAILCALL jmp void call<14u>() # TAILCALL jmp void call<15u>() # TAILCALL jmp void call<16u>() # TAILCALL jmp void call<17u>() # TAILCALL jmp void call<18u>() # TAILCALL jmp void call<19u>() # TAILCALL .LJTI0_0: .quad .LBB0_2 .quad .LBB0_3 .quad .LBB0_4 .quad .LBB0_5 .quad .LBB0_6 .quad .LBB0_7 .quad .LBB0_8 .quad .LBB0_9 .quad .LBB0_10 .quad .LBB0_11 .quad .LBB0_12 .quad .LBB0_13 .quad .LBB0_14 .quad .LBB0_15 .quad .LBB0_16 .quad .LBB0_17 .quad .LBB0_18 .quad .LBB0_19 .quad .LBB0_20 .quad .LBB0_21 I can say that it is not using a jump table -- 4 comparison instructions are clearly visible: 13FE81C51 cmp qword ptr [rsp+30h],1 13FE81C57 je testSwitch+73h (13FE81C73h) 13FE81C59 cmp qword ptr [rsp+30h],2 13FE81C5F je testSwitch+87h (13FE81C87h) 13FE81C61 cmp qword ptr [rsp+30h],3 13FE81C67 je testSwitch+9Bh (13FE81C9Bh) 13FE81C69 cmp qword ptr [rsp+30h],4 13FE81C6F je testSwitch+0AFh (13FE81CAFh) A jump table based solution does not use comparison at all. Either not enough branches to cause the compiler to generate a jump table, or your compiler simply doesn't generate them. I'm not sure which.

EDIT 2014: There has been some discussion elsewhere from people familiar with the LLVM optimizer saying that the jump table optimization can be important in many scenarios; e.g. in cases where there is an enumeration with many values and many cases against values in said enumeration. That said, I stand by what I said above in 2011 -- too often I see people thinking "if I make it a switch, it'll be the same time no matter how many cases I have" -- and that's completely false. Even with a jump table you get the indirect jump cost and you pay for entries in the table for each case; and memory bandwidth is a Big Deal on modern hardware.

为可读性编写代码。任何有价值的编译器都会看到一个if / else if阶梯，并将其转换为等效的开关，反之亦然，如果这样做会更快的话。

注意，当一个switch没有编译到一个跳转表时，你经常可以写if比switch更有效…

(1)如果情况是有序的，而不是对所有N进行最坏的情况测试，你可以写你的if在上半部分或下半部分测试if，然后在每个一半，二分搜索风格…结果最坏的情况是logN而不是N

(2)如果某些情况/组比其他情况更频繁，那么设计你的if首先隔离这些情况可以加快平均时间

一个好的优化编译器，如MSVC可以生成:

一个简单的跳跃表，如果情况被安排在一个很好的长范围 如果有很多空隙，则使用稀疏(两级)跳转表 如果情况的数量很小或值为 不要靠得太近 以上的组合，如果情况代表几组 间隔太近。

简而言之，如果转换看起来比一系列if慢，编译器可能会直接将它转换为一个if。它很可能不仅仅是每个情况下的比较序列，而是一个二叉搜索树。请看这里的例子。

但不知道为什么一个更快，一个更慢。

这其实不难解释……如果你还记得错误预测的分支比正确预测的分支贵几十到几百倍。

In the % 20 version, the first case/if is always the one that hits. Modern CPUs "learn" which branches are usually taken and which are not, so they can easily predict how this branch will behave on almost every iteration of the loop. That explains why the "if" version flies; it never has to execute anything past the first test, and it (correctly) predicts the result of that test for most of the iterations. Obviously the "switch" is implemented slightly differently -- perhaps even a jump table, which can be slow thanks to the computed branch.

在% 21版本中，分支基本上是随机的。因此，不仅每次迭代都有许多线程执行，CPU也无法猜测它们将朝哪个方向运行。在这种情况下，跳转表(或其他“切换”优化)可能会有所帮助。

很难预测一段代码在现代编译器和CPU上的表现，而且每一代都会变得更加困难。最好的建议是:“连试都不用试;总是概要”。每年，这种建议都会变得越来越好，而能够成功忽略它的人也会越来越少。

所有这些都是说，我上面的解释在很大程度上是一种猜测。: -)

我对此很感兴趣，并查看了可以对您的示例进行哪些更改以使其更快地运行switch语句。

如果你有40个If语句，并添加一个0大小写，那么If块将比等效的switch语句运行得慢。我在这里有结果:https://www.ideone.com/KZeCz。

删除0大小写的效果可以在这里看到:https://www.ideone.com/LFnrX。

不，这些是if then跳转else if then跳转else。跳转表会有一个地址表或者使用散列之类的。

快或慢是主观的。例如，您可以将用例1作为最后一个而不是第一个，如果您的测试程序或实际应用程序在大多数情况下使用用例1，那么这种实现的代码将会变慢。因此，仅仅根据实现重新排列案例列表，就可以产生很大的不同。

If you had used cases 0-3 instead of 1-4 the compiler might have used a jump table, the compiler should have figured out removing your +1 anyway. Perhaps it was the small number of items. Had you made it 0 - 15 or 0 - 31 for example it may have implemented it with a table or used some other shortcut. The compiler is free to choose how it implements things so long as it meets the functionality of the source code. And this gets into compiler differences and version differences and optimization differences. If you want a jump table, make a jump table, if you want an if-then-else tree make an if-then-else tree. If you want the compiler to decide, use a switch/case statement.