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

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

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

编译器可以自由地将switch语句编译为相当于if-statement的代码，或者创建一个跳转表。它可能会根据你在编译器选项中指定的内容来选择一个执行最快的语句，或者生成最小的代码——所以最坏的情况下它将与if语句相同的速度

我相信编译器会做出最好的选择，并专注于使代码最有可读性。

如果情况的数量变得非常大，那么跳转表将比一系列的If快得多。但是，如果值之间的步长非常大，那么跳转表可能会变得很大，编译器可能会选择不生成一个。

您如何知道您的计算机在交换机测试循环期间没有执行与测试无关的任务，并且在if测试循环期间执行较少的任务?你的测试结果没有显示:

差别非常小 只有一个结果，而不是一系列的结果 病例太少了

我的结果:

我添加:

printf("counter: %u\n", counter);

到最后，这样它就不会优化循环，因为计数器在你的例子中从未使用过，那么为什么编译器要执行循环?立即，即使在这样的微观基准下，转换也总是获胜。

你代码的另一个问题是:

switch (counter % 4 + 1)

在你的开关循环中，相对

const size_t c = counter % 4 + 1; 

在if循环中。如果你解决了这个问题，会有很大的不同。我认为，将语句放在switch语句中会触发编译器直接将值发送到CPU寄存器中，而不是先将其放入堆栈中。因此，这有利于switch语句，而不是平衡测试。

哦，我认为你应该在测试之间重置计数器。事实上，你可能应该使用一些随机数，而不是+1，+2，+3等，因为它可能会优化那里的某些东西。例如，我所说的随机数是指基于当前时间的数字。否则，编译器可能会把你的两个函数都转换成一个很长的数学运算，甚至不需要任何循环。

我修改了Ryan的代码，以确保编译器不能在代码运行之前解决问题:

#include <stdlib.h>
#include <stdio.h>
#include <time.h>

#define MAX_COUNT (1 << 26)
size_t counter = 0;

long long testSwitch()
{
    clock_t start = clock();
    size_t i;
    for (i = 0; i < MAX_COUNT; i++)
    {
        const size_t c = rand() % 20 + 1;

        switch (c)
        {
                case 1: counter += 20; break;
                case 2: counter += 33; break;
                case 3: counter += 62; break;
                case 4: counter += 15; break;
                case 5: counter += 416; break;
                case 6: counter += 3545; break;
                case 7: counter += 23; break;
                case 8: counter += 81; break;
                case 9: counter += 256; break;
                case 10: counter += 15865; break;
                case 11: counter += 3234; break;
                case 12: counter += 22345; break;
                case 13: counter += 1242; break;
                case 14: counter += 12341; break;
                case 15: counter += 41; break;
                case 16: counter += 34321; break;
                case 17: counter += 232; break;
                case 18: counter += 144231; break;
                case 19: counter += 32; break;
                case 20: counter += 1231; break;
        }
    }
    return 1000 * (long long)(clock() - start) / CLOCKS_PER_SEC;
}

long long testIf()
{
    clock_t start = clock();
    size_t i;
    for (i = 0; i < MAX_COUNT; i++)
    {
        const size_t c = rand() % 20 + 1;
        if (c == 1) { counter += 20; }
        else if (c == 2) { counter += 33; }
        else if (c == 3) { counter += 62; }
        else if (c == 4) { counter += 15; }
        else if (c == 5) { counter += 416; }
        else if (c == 6) { counter += 3545; }
        else if (c == 7) { counter += 23; }
        else if (c == 8) { counter += 81; }
        else if (c == 9) { counter += 256; }
        else if (c == 10) { counter += 15865; }
        else if (c == 11) { counter += 3234; }
        else if (c == 12) { counter += 22345; }
        else if (c == 13) { counter += 1242; }
        else if (c == 14) { counter += 12341; }
        else if (c == 15) { counter += 41; }
        else if (c == 16) { counter += 34321; }
        else if (c == 17) { counter += 232; }
        else if (c == 18) { counter += 144231; }
        else if (c == 19) { counter += 32; }
        else if (c == 20) { counter += 1231; }
    }
    return 1000 * (long long)(clock() - start) / CLOCKS_PER_SEC;
}

int main()
{
    srand(time(NULL));
    printf("Starting...\n");
    printf("Switch statement: %lld ms\n", testSwitch()); fflush(stdout);
    printf("counter: %d\n", counter);
    counter = 0;
    srand(time(NULL));
    printf("If     statement: %lld ms\n", testIf()); fflush(stdout);
    printf("counter: %d\n", counter);
} 

开关:3740 如果:3980

(多次尝试的结果相似)

我还将case /if的数量减少到5，切换功能仍然获胜。

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

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

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

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

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

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

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

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