Google Benchmark的DoNotOptimize与volatile：哪个更适合阻止编译器优化？

效果是否完全相同？ #

不完全相同，二者的核心差异在于对编译器优化的限制范围：

• 第一种方式 volatile result = compute();：
  编译器会将volatile变量视为可能被外部修改/读取的对象，因此必须保留compute()调用以完成赋值。但这种方式会额外限制编译器对compute()本身的优化——比如无法内联函数、无法进行常量传播或循环展开等，因为volatile赋值被视为一个必须执行的“可见副作用”，编译器不能对其上游的计算逻辑做激进优化。
• 第二种方式 bool result = compute(); DoNotOptimize(result);：
  DoNotOptimize是基准测试框架（如Google Benchmark）提供的专用工具，它通过编译器屏障或内嵌汇编等机制，告诉编译器result会被“实际使用”，从而保留compute()调用，但不会限制编译器对compute()内部的优化。编译器仍然可以正常内联、优化compute()的逻辑，只需要确保最终结果传递给DoNotOptimize即可。

哪种方式更好？ #

优先选择第二种方式（DoNotOptimize），原因如下：

• 它是基准测试场景的标准方案，专门为“保留函数调用但不干扰函数内部优化”设计，能更准确地反映compute()的真实运行性能。
• 第一种方式的volatile会强制编译器放弃对compute()的合理优化，导致测试结果偏离实际代码中函数的运行表现（实际代码中result通常不会是volatile，编译器会做更多优化）。
• 若compute()返回复杂类型，volatile赋值可能会强制将结果写入内存而非留在寄存器，额外引入不必要的内存开销，进一步影响性能测试的准确性。

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