为何数组索引式循环比switch case慢3倍？技术疑问

你的测试结果是编译器优化能力、内存访问开销和分支预测效率共同作用的结果，具体拆解如下：

1. switch-case的极致优化 #

Clang在O3级别下对连续case的switch会做两个关键优化：

• 跳转表转换：把switch转换成直接的地址跳转表，消除条件判断开销，分支预测命中率接近100%；
• 全内联：每个stateN函数逻辑简单，编译器会直接把代码内联到对应switch分支，彻底消除函数调用的栈操作和间接跳转开销；
• 常量取模优化：每个stateN里的模数（比如89、83）是编译期常量，编译器会把var % 89替换成乘法逆元+移位的高效指令，比运行时取模快数倍。

这些优化让switch-case的控制流和运算逻辑被压缩到极致，性能自然最优。

2. 函数指针的性能瓶颈 #

函数指针调用属于间接跳转，编译器无法提前确定要调用的函数地址，因此无法做内联优化，必须保留函数调用的栈操作；同时分支预测器对间接跳转的命中率远低于switch的跳转表，这两点导致其性能不如switch-case，符合你的预期。

3. 数组索引方案的核心劣势 #

看似简单的数组索引方案，恰恰因为“运行时动态取值”的特性，挡住了编译器的大部分优化，同时引入额外开销：

• 内存访问开销：myArr[myArrIndex]每次都要从栈内存加载数值（哪怕是L1缓存，也比直接用寄存器里的常量慢），而switch-case里的模数是硬编码到指令中的常量，完全不需要内存访问；
• 无法优化的运行时取模：因为模数是运行时从数组读取的变量，编译器无法提前计算乘法逆元，只能用硬件指令做除法取模，速度远慢于常量取模的优化版本；
• 分支预测难度高：数组里的模数是变化的，myInt % x == 0的条件没有固定规律，分支预测器很难命中，频繁的分支预测失败会导致CPU流水线停滞；
• 数据依赖链：myArrIndex的更新依赖前一次的索引值，形成循环内的依赖链，限制了编译器的指令级并行优化空间。

这些因素叠加，就让这个看似最简单的方案成了三者中性能最差的。

测试代码片段 #

SwitchCase代码 #

unsigned state1(unsigned *state, unsigned *counter, unsigned var)
{
  if(0 == (var % 89))
  {
    *state = 2;
    *counter += 1;
    return var;
  }

  return var -1;
}

// ... 省略state2到state9的实现

unsigned int myInt = numberOfTries;
unsigned int state = 1;
unsigned int counter = 0;

while (0 != myInt)
{      
  switch (state)
  {
    case 1:
      myInt = state1(&state, &counter, myInt);
      break;   
// ... 省略case2到case9的分支

    case 10:
      myInt = state10(&state, &counter, myInt);
      break;
  }
}

ForLoopMod代码 #

unsigned int myArr[] = { 89, 83, 79, 73, 71, 67, 61, 59, 53, 47 };
unsigned int myArrIndex = 0;
unsigned int myInt = numberOfTries;
unsigned int counter = 0;

while (0 != myInt)
{
  if (0 == (myInt % myArr[myArrIndex]))
  {
    counter++;
    myArrIndex++;
    myArrIndex %= 10;
  }
  else
  {
    myInt--;
  }
}

内容的提问来源于stack exchange，提问作者Even Elshaug Almås