无分支编程优化CPU流水线停顿（分支预测失败）的效果与风险问询

• 没有绝对结论，核心取决于你的实际业务场景，判断基准是原switch分支的预测失败率：
  • 如果输入分布高度不可预测，原switch的分支预测失败率超过10%，那无分支函数表的收益会非常明显：一次分支预测失败的开销通常在10_{30个CPU时钟周期，而缓存命中的函数表访问+间接跳转的固定开销通常只有3}5个时钟周期，性能会远超switch实现。
  • 如果输入分布高度可预测，比如95%以上的请求都命中同一个case，那switch的性能会更好：预测正确的分支开销通常只有1个时钟周期甚至0（流水线预取正确），反而比函数表的固定开销更低。
• 额外需要注意MSVC对switch的默认编译逻辑：如果你的case值是连续的，MSVC默认就会把switch编译成内置跳转表，逻辑和你自己实现的函数表高度相似，这种情况下你自己写的函数表很难比编译器生成的跳转表更快，反而可能因为函数调用的栈帧开销更慢；只有当你的case值不连续，MSVC把switch编译成if-else分支链的时候，手动实现的连续索引函数表才会有明显收益。
• 最终性能结论必须依赖实际测试：建议用MSVC的__rdtsc()内置函数统计单轮执行的平均时钟周期，测试用的输入数据要完全匹配生产环境的分布，不要用全随机或者全固定的人造数据，否则测试结果没有参考价值。

• 可维护性下降：原switch的所有分支逻辑集中在同一处，直观易读，函数表实现需要把每个分支拆成独立函数，代码分散，后续迭代修改逻辑很容易出现遗漏。
• 安全风险提升：如果函数表的输入索引没有做严格的边界校验，非法输入会直接跳转到非法内存地址，轻则程序崩溃，重则引发任意代码执行漏洞；而switch实现哪怕输入不命中任何case，只要有default分支或者编译器默认的兜底逻辑，不会产生地址跳转类的安全问题。
• 额外的固定开销：如果每个分支的逻辑非常简短（只有几行运算），函数调用的栈帧创建、参数传递、返回值处理的开销，甚至会超过分支预测失败的开销，反而比switch更慢；同时间接跳转本身也存在BTB（分支目标缓存） miss的可能，如果函数表入口太多、调用太分散，间接跳转本身也会产生预测失败开销。
• 编译器优化受限：switch的分支逻辑编译器可以做常量传播、死代码消除、分支内联等优化，而函数表的间接调用属于运行时确定目标的逻辑，编译器很难做跨调用的优化，甚至无法把小函数内联到主循环中，反而会生成执行效率更低的代码。
• 调试难度提升：switch实现可以很方便的给每个case加断点，快速判断当前命中的分支；函数表实现的跳转逻辑是运行时动态确定的，调试时很难快速定位当前执行的分支逻辑。

内容的提问来源于stack exchange，提问作者sunkue