C语言循环执行次数降近3倍耗时无提升的原因及解决方法

核心原因 #

• 计时器精度不足：两次测试的耗时均为2ms左右，远低于clock()函数的常规精度范围（通常为1~10ms），测试误差完全覆盖了真实的耗时差异，是观察不到3倍性能差的最直接原因。
• 循环瓶颈为内存访问延迟：每次循环的耗时99%以上来自两次依赖型随机内存访问：先读取tex[i]的值，再用该值作为索引读取rand_arr的元素。由于步长远大于CPU缓存行大小（通常为64字节），缓存预取完全失效，几乎每次访问都会触发缓存miss，内存访问延迟占了绝对大头，循环计数、变量自增等CPU运算的开销可以忽略不计。
• 缓存命中率无本质差异：两次测试的平均步长分别约为128和384，都远大于缓存行大小，tex数组的访问缓存命中率都不足1%，内存访问的平均延迟几乎一致，进一步缩小了耗时差异。
• 编译优化无法覆盖内存瓶颈：不同编译优化等级结果一致，是因为编译器优化只能降低CPU运算侧的开销，无法改变随机内存访问的延迟，而这部分刚好是代码的核心瓶颈，所以O0到O3的优化效果不会体现在耗时上。

调整方案 #

• 放大测试量级：将Len宏定义从10000000提升到1000000000，或者将两个测试循环包裹在额外的重复执行外层循环中，把单次测试的总耗时拉长到1秒以上，消除计时器精度误差的干扰，此时就能观察到和循环次数匹配的耗时差异。
• 验证循环开销的线性关系：如果要验证循环次数和耗时的正相关，可将循环内的内存访问替换为寄存器变量运算，消除内存瓶颈后即可看到3倍循环次数带来的3倍左右耗时差。
• 针对实际业务场景优化：如果真实业务逻辑和测试代码逻辑类似，要拿到预期的优化效果，核心要优先优化内存访问命中率：比如调整数据结构让访问步长小于64字节，或者将随机访问改为连续访问，让CPU缓存预取机制生效，此时降低循环次数才能转化为实际的性能提升。

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