GCC O3优化下函数指针实现为何比switch语句慢很多？

核心性能差异原因 #

• 你开启了-O3高优化等级，编译器对switch分支的优化能力远强于函数指针间接调用：
  1. mySum和mySub都是逻辑极简单的小函数，在switch分支场景下编译器可以直接把函数逻辑内联展开，完全消除函数调用开销。
  2. 编译器可以轻易推导你的循环逻辑：每次循环交替调用加1和减1，累计100亿次后startingValue的值始终是初始值25，所以直接把整个100亿次的switch循环完全优化消除了，根本没有执行循环，所以瞬间跑完。
• 函数指针场景存在天然的优化限制：
  1. 函数指针的间接调用属于动态分发，默认情况下编译器不会对这类调用做内联优化，每次调用都要走完整的函数调用流程：参数压栈、地址跳转、栈帧维护、结果返回，单次开销本身就比内联的switch逻辑高。
  2. 编译器无法对函数指针的动态调用做全局逻辑推导，没法确认100亿次调用后的结果是固定值，所以只能老老实实执行完全部100亿次循环，累计下来就产生了几十秒的耗时。

代码存在的问题 #

代码逻辑本身没有错误，两种实现的输出结果一致即可证明逻辑正确性，但性能测试的设计存在严重偏差：你触发了编译器对两种实现的优化等级差异，测出来的不是switch和函数指针的真实性能差，而是“被完全优化掉的代码”和“实际执行的代码”的差异。

排查思路 #

• 查看生成的汇编代码验证优化结果：执行gcc -S -O3 -Wall -Wno-unused -std=c99 main.c生成汇编文件main.s，直接查看switch对应的循环段是否存在，即可确认是不是被优化消除。
• 修正测试用例避免死代码消除：比如把currentOperation的取值改为从标准输入读取，或者用运行时生成的随机数，让编译器无法在编译期预测分支走向，就不会把整个循环优化掉。
• 用性能分析工具定位耗时：使用perf record ./test && perf report可以直接看到两种实现的指令执行数、CPU占用占比，很容易就能发现switch的循环是否实际执行。
• 调整优化等级验证：把-O3改为-O0关闭优化后重新编译运行，两者的耗时差异会缩小到合理范围，不会出现几十秒的差距。

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