以下是旧的(现在很难找到)bench++基准测试的一些结果:

Test Name:   F000003                         Class Name:  Style
CPU Time:       0.781  nanoseconds           plus or minus     0.0715
Wall/CPU:        1.00  ratio.                Iteration Count:  1677721600
Test Description:
 Time to test a global using a 2-way if/else if statement
 compare this test with F000004

Test Name:   F000004                         Class Name:  Style
CPU Time:        1.53  nanoseconds           plus or minus     0.0767
Wall/CPU:        1.00  ratio.                Iteration Count:  1677721600
Test Description:
 Time to test a global using a 2-way switch statement
 compare this test with F000003

Test Name:   F000005                         Class Name:  Style
CPU Time:        7.70  nanoseconds           plus or minus      0.385
Wall/CPU:        1.00  ratio.                Iteration Count:  1677721600
Test Description:
 Time to test a global using a 10-way if/else if statement
 compare this test with F000006

Test Name:   F000006                         Class Name:  Style
CPU Time:        2.00  nanoseconds           plus or minus     0.0999
Wall/CPU:        1.00  ratio.                Iteration Count:  1677721600
Test Description:
 Time to test a global using a 10-way switch statement
 compare this test with F000005

Test Name:   F000007                         Class Name:  Style
CPU Time:        3.41  nanoseconds           plus or minus      0.171
Wall/CPU:        1.00  ratio.                Iteration Count:  1677721600
Test Description:
 Time to test a global using a 10-way sparse switch statement
 compare this test with F000005 and F000006

从中我们可以看到(在这台机器上，使用这个编译器——vc++ 9.0 x64)，每个if测试大约需要0.7纳秒。随着测试数量的增加，时间几乎是完全线性的。

使用switch语句，2路测试和10路测试之间的速度几乎没有区别，只要值是密集的。使用稀疏值的10路测试所花费的时间大约是使用密集值的10路测试的1.6倍——但即使使用稀疏值，仍然比使用10路if/else if的速度快两倍。

底线:仅仅使用一个4-way测试并不能真正告诉你switch vs if/else的性能。如果您查看这段代码中的数字，就可以很容易地插入一个事实，即对于4路测试，我们期望两者产生非常相似的结果(If /else为~2.8纳秒，开关为~2.0纳秒)。

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

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

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

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

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阶梯，并将其转换为等效的开关，反之亦然，如果这样做会更快的话。

I'll answer 2) and make some general comments. 2) No, there is no jump table in the assembly code you've posted. A jump table is a table of jump destinations, and one or two instructions to jump directly to an indexed location from the table. A jump table would make more sense when there are many possible switch destinations. Maybe the optimiser knows that simple if else logic is faster unless the number of destinations is greater than some threshold. Try your example again with say 20 possibilities instead of 4.

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

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

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上的表现，而且每一代都会变得更加困难。最好的建议是:“连试都不用试;总是概要”。每年，这种建议都会变得越来越好，而能够成功忽略它的人也会越来越少。

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

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

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

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