"你的代码很快——如果你走运"：为什么你的微基准测试在说谎

简单来说

开发人员展示了同一段代码在与算法无关的参数下，可能快30%或慢30%：链接时符号的顺序、环境变量的大小、内存对齐。换句话说，我们测量到的微秒级差异很大程度上取决于运气。

故事

作者在 tiki.li/blog/lucky_code 上重新审视了编译器中已知的一个话题（Emery Berger, Stabilizer, ASPLOS 2013），并将其更新：他执行同一个二进制文件，不修改它，但改变周边参数（构建目录的名称、对象文件的链接顺序、$PATH 的大小）。运行时间显著变化，在微基准测试中达到30%以上。原因在于指令在L1i/uop缓存中的对齐、x86解码器和分支预测，这些都对代码的虚拟地址敏感。

让所有人都感到不安的一点是：在现实生活中，我们比较PR的前后版本，注意到有8%的提升，然后合并。这些提升中有多少是真实的信号？有多少是对齐的噪声？

深入探讨

• Stabilizer（Berger 2013）在每次运行时随机分配堆栈、堆和代码 - 测量结果变成分布，而不是点。
• Hyperfine + -warmup + -runs 50 无法解决问题：它进行平均，但每次运行同一个二进制时对齐仍然相同。
• 正确的做法：使用随机偏移量重新编译（Stabilizer 或手动填充）或者使用 -randomize-address 执行，并报告95%置信区间，而不是平均值。

结论

对工艺有三个影响。一：在单一微基准测试中低于10%的性能提升可能是噪声。拒绝它，或者在随机化下重新测试。二：CI中的性能回归（如Codspeed）必须采用随机化，否则我们会忽略真实的回归并对噪声感到恐慌。三：编译器和运行时的营销基准测试（如Bun vs Node, Zig vs C…）需要用这个过滤器来阅读。在这样的水平上，性能与构建工程的关系与算法的关系一样大。