为何Benchmark与StopWatch的性能测试结果差异如此巨大？

测量方式的合法性 #

两种测量方式本身都是有效的，但适用场景和优化逻辑完全不同，不能直接等同对比。

差异的核心原因 #

• 手动StopWatch.GetTimestamp()测量的问题：
  • 缺少预热：第一次执行空循环时，JIT即时编译器需要先编译这段代码，你测量的8388us很可能包含了JIT编译的开销，而非纯循环耗时。
  • 优化不足：手动测试时，JIT可能不会启用激进优化（比如循环展开、无意义代码消除），尤其是如果你的测试代码是在Debug模式下运行，或者没有触发JIT的优化阈值。
  • 无统计处理：单次测量容易受到系统线程调度、GC等干扰，结果波动大。
• BenchmarkRunner（BenchmarkDotNet框架）的优化逻辑：
  • 自动预热：先执行多轮循环让JIT完成编译和优化，确保测量的是已优化后的代码性能。
  • 强制最高优化：默认在Release模式下运行，引导JIT启用Optimize=true级别的优化，空循环会被大幅优化（比如循环展开减少迭代次数，甚至部分消除无意义操作）。
  • 统计降噪：多次运行取平均，排除系统干扰，结果更接近代码的真实最优性能。

结果采信建议 #

优先采信BenchmarkRunner的结果。

BenchmarkDotNet是.NET生态中专门做性能测试的成熟工具，它帮你处理了所有手动测试容易忽略的细节（预热、优化、统计），给出的是代码在生产环境持续运行时的真实性能表现。

如果你的场景是代码仅单次执行（比如临时脚本、启动即退出的工具），StopWatch的结果可能更贴近实际，但这种场景极少——大部分生产代码都会持续运行，JIT会完成优化，所以Benchmark的结果参考价值更高。

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