Google Benchmark 默认报告的是多次运行、剔除离群值后拟合的每次迭代平均耗时（纳秒级），比单次 std::chrono 测量更准确；其通过预热、防优化、多轮采样和统计拟合保障纳秒级可信度。
Google Benchmark 本身不直接输出“纳秒级单次执行时间”，它默认报告的是**每次迭代的平均耗时（单位：纳秒）**，但这个值是多次运行、剔除离群值、统计拟合后的结果——比手写 std::chrono::high_resolution_clock 测一次更可信，也更接近真实纳秒量级行为。关键不是“能不能测到纳秒”，而是“测得准不准”。
为什么不能靠 std::chrono 手动测纳秒？
手动用 std::chrono::steady_clock::now() 包裹一次函数调用，得到的数字大概率是噪声：CPU 频率跳变、缓存未命中、上下文切换、编译器优化掉整段逻辑……都会让单次测量完全失真。Google Benchmark 的价值在于它自动做以下事：
- 预热 CPU 和缓存（warm-up iterations）
- 重复运行数十至数百次，剔除最高/最低 10% 离群值
- 用最小二乘法拟合多轮采样数据，估算稳定态耗时
- 强制编译器不把待测逻辑优化掉（靠
benchmark::DoNotOptimize）
所以，想看纳秒级性能，必须用 Benchmark 框架本身的方式，而不是绕过它去“提纯单次”。
BENCHMARK 函数里怎么写才能反映真实纳秒开销？
核心原则：让被测逻辑足够轻、足够可控，并显式防止优化。比如测试一个加法函数：
立即学习“C++免费学习笔记（深入）”；
#include <benchmark/benchmark.h>
static void BM_Add(benchmark::State& state) {
for (auto _ : state) {
int a = state.range(0);
int b = state.range(1);
int result;
result = a + b; // 这行会被优化掉！
benchmark::DoNotOptimize(result); // 必须加这句
}
}
BENCHMARK(BM_Add)->Args({1, 2})->Unit(benchmark::kNanosecond);
-
benchmark::DoNotOptimize(result)是刚需——没有它，a + b可能整个消失，测出来就是 0ns -
->Unit(benchmark::kNanosecond)只是控制输出单位，不影响计时精度；实际底层仍是纳秒级时钟源 - 别在循环外声明变量（如
int result;），除非你明确想测栈分配开销；否则放循环内，让每次迭代都干净独立 - 如果函数有副作用（比如修改全局状态），要用
benchmark::ClobberMemory()防止指令重排干扰
运行时怎么拿到靠谱的纳秒数据？
编译后直接运行，加参数确保环境干净：
./benchmarks --benchmark_filter=Add --benchmark_repetitions=5 --benchmark_report_aggregates_only=true
-
--benchmark_repetitions=5：跑 5 轮完整测试（每轮含多次迭代），用于评估结果稳定性 -
--benchmark_report_aggregates_only=true：只输出均值、标准差，不刷每轮明细，避免眼花 - 务必在
Release模式下构建（-O2或-O3），且禁用调试宏（如-DNDEBUG）；Debug 模式下的结果毫无参考价值 - Linux 下建议加
taskset -c 0绑定单核，减少调度抖动；macOS 可用sudo powermetrics监控频率是否稳定
容易被忽略的纳秒级陷阱
真正影响纳秒级数据可信度的，往往不是代码写法，而是环境和认知偏差：
- CPU 频率没锁死：
scaling_governor是ondemand？会导致同一段代码前后两次运行差 20%+；应设为performance - 测试规模太小：比如只测 1 次加法，框架可能连一次 cache line 加载都没完成，测出来是“内存延迟主导”而非“计算延迟”
- 误读
real_time和cpu_time：前者含调度、中断等系统开销，后者是纯 CPU 时间；微基准中优先看cpu_time - 忘了关 ASLR：
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space，否则每次加载地址不同，影响 branch predictor 表现
纳秒级差异往往藏在硬件细节里——不是 Benchmark 不够细，而是你得先让硬件表现得足够可预测。
