为何clock_gettime的计时结果会因函数计时方式不同而存在差异？

1. result1额外100ns的来源 #

你看到的100ns是function_a的实际执行开销——注释function_a后，两次连续clock_gettime的基线耗时是30ns，包含function_a时result1为130ns，差值100ns就是function_a真正的运行成本。

别被“少量控制语句和指针解引用”的表象迷惑，这些操作在现代CPU上的开销远非单周期能覆盖：

• 指针解引用若遇到TLB（翻译后备缓冲器）不命中，单次延迟就能达到几十到上百ns；哪怕是缓存不命中，L2/L3缓存的访问延迟也会显著拉高耗时。
• 控制语句的分支跳转如果触发分支预测失败，会导致CPU流水线清空，单次错误就能带来10-20ns的开销，叠加后总耗时会明显上升。
• clock_gettime本身也会占用CPU指令端口、缓存带宽等资源，和function_a的执行存在资源竞争，进一步放大了总耗时。

2. function_a对function_b耗时的影响 #

注释function_a后result2仅从630ns降至600ns，说明function_a的执行改变了CPU的运行状态，间接影响了function_b的效率，常见原因包括：

• 缓存状态污染：function_a加载的缓存行挤占了function_b所需的数据/指令缓存空间，导致function_b执行时出现更多缓存不命中；去掉function_a后，预热阶段加载的function_b相关缓存已处于就绪状态，所以耗时仅减少少量额外开销。
• 分支预测器状态干扰：function_a的分支操作打乱了分支预测器的历史状态，降低了function_b的分支预测准确率；去掉function_a后，分支预测器在预热后处于更优状态，function_b的耗时恢复到接近自身基线。
• 流水线资源占用：function_a的指令占用了CPU流水线的执行端口，导致function_b的指令发射延迟增加，整体耗时被拉长。

补充验证建议 #

• 单独测量function_a耗时：将function_a放在两次clock_gettime之间，循环数百万次取平均，直接获取其真实开销。
• 用性能工具统计细节：通过perf stat查看有无function_a时的L1/L2缓存命中率、TLB miss次数、分支预测失败率，定位具体耗时来源。

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