应优先使用 std::chrono::steady_clock 测量执行时间,因其严格单调且不受系统时间调整影响;high_resolution_clock 虽常用但跨平台行为不一致,system_clock 则可能被 NTP 等干扰。

std::chrono::high_resolution_clock 是最常用但不总是最准的选择
多数场景下用 std::chrono::high_resolution_clock 没问题,但它在不同平台行为不一致:Windows 上通常映射到 QueryPerformanceCounter,Linux 上可能是 clock_gettime(CLOCK_MONOTONIC),但 C++ 标准只要求它“尽可能高精度”,不保证单调性或跨平台一致性。若需严格单调、抗系统时间调整,应改用 std::chrono::steady_clock。
- 测量代码段执行时间,优先选
std::chrono::steady_clock—— 它不随系统时间跳变而偏移 -
high_resolution_clock在某些旧编译器(如 GCC 4.8)可能退化为system_clock,导致毫秒级误差 - 不要用
system_clock测执行时间——它反映挂钟时间,可能被 NTP 调整、夏令时等干扰
正确获取两次时间点并计算差值的写法
核心是避免隐式类型转换丢失精度,且必须用 duration_cast 显式转换单位。直接对 time_point 做减法得到的是 duration,但它的底层计数器单位因实现而异(纳秒/微秒/拍秒),不能直接当浮点数用。
auto start = std::chrono::steady_clock::now(); // ... your code ... auto end = std::chrono::steady_clock::now(); auto elapsed = std::chrono::duration_cast<std::chrono::nanoseconds>(end - start); std::cout << "Time: " << elapsed.count() << " ns\n";
- 用
duration_cast而非 C 风格强转:(double)(end - start).count()会截断,且单位不明 - 若要毫秒浮点值,写成
std::chrono::duration<double std::milli>(end - start).count()</double> - 避免把
now()结果存成auto后跨作用域使用——某些 libstdc++ 实现中,time_point的模板参数过深可能导致 ODR 违规
重复测量时要注意 warmup 和编译器优化干扰
单次测量容易受 CPU 频率突变、缓存未命中、指令重排影响。实际性能分析必须做多次采样,并剔除异常值。同时,编译器可能把“无副作用”的待测代码整个优化掉。
- 用
volatile或asm volatile("" ::: "memory")防止关键计算被优化(尤其纯计算型代码段) - 首次运行前加一次 warmup:调用待测函数一次,让指令/数据进入 L1 缓存和分支预测器
- 至少测 5–10 次,取中位数而非平均值——避免被某次缺页或中断拉高耗时
- 用
std::chrono::nanoseconds::min()判断是否真有耗时(某些极快操作可能返回 0)
Windows 下 QueryPerformanceCounter 的替代方案更可控
如果你在 Windows 上需要确定性最高的结果,且已知目标环境支持,可绕过 std::chrono 直接调用 WinAPI:QueryPerformanceFrequency + QueryPerformanceCounter。它比标准库封装少一层抽象,也规避了某些 MSVC 版本中 steady_clock::now() 的锁竞争开销。
立即学习“C++免费学习笔记(深入)”;
- 仅限 Windows;Linux 应用请坚持用
steady_clock+clock_gettime(CLOCK_MONOTONIC) - 注意
QueryPerformanceCounter在某些虚拟机或老 CPU 上可能不准(TSC 不稳定),需检查QueryPerformanceFrequency返回值是否 > 0 - 标准库的
steady_clock在现代 MSVC(19.20+)和 Clang/LLVM 中已基本等价于该 API,除非你正在调试 nanosecond 级别抖动,否则不必手动替换
精度不是靠选对时钟就万事大吉的——CPU 频率缩放、上下文切换、TLB miss、甚至 std::chrono::now() 自身调用开销(通常几十纳秒)都会混入测量结果。真正可靠的性能对比,永远依赖统计方法和可控环境。











