C++ 怎么计算程序耗时 C++ chrono高精度计时器使用教程【测试】

应优先使用 std::chrono::steady_clock 测量耗时，因其单调递增、不受系统时间调整影响；high_resolution_clock 行为因平台而异，不可靠；计时需两次 now() 并用 duration_cast 转换。

chrono::high_resolution_clock 是最常用但未必最稳的选择

在多数场景下，std::chrono::high_resolution_clock 看起来是“高精度”的默认答案，但它在不同平台行为不一致：Windows 上通常映射为 steady_clock，而 Linux 上可能退化为 system_clock（受系统时间调整影响）。如果你测的是算法执行时间，必须避免被 NTP 校时或手动改系统时间干扰。

实操建议：

• 优先用 std::chrono::steady_clock——它保证单调递增，不受系统时间变更影响，专为测量耗时设计
• 若需和系统时间对齐（比如打日志时间戳），再单独调用 system_clock::now()
• 不要依赖 high_resolution_clock::is_steady 的返回值做运行时分支——C++ 标准只要求它“尽力”，不保证跨平台一致

计时代码模板必须包含两次 now() + duration_cast

常见错误是只调一次 now()，或漏掉 duration_cast 直接输出 time_point。实际上 time_point 本身不能直接相减成“毫秒数”，必须显式转为目标时长类型。

正确写法示例：

立即学习“C++免费学习笔记（深入）”；

auto start = std::chrono::steady_clock::now();
// ... your code here ...
auto end = std::chrono::steady_clock::now();
auto elapsed = std::chrono::duration_cast(end - start);
std::cout << "cost: " << elapsed.count() << " μs\n";

注意点：

幻舟AI

专为短片创作者打造的AI创作平台

下载

• duration_cast 截断而非四舍五入，比如 1234.9μs 转 milliseconds 得到 1ms
• 想保留小数？用 std::chrono::duration 或除以 1000.0 手动换算
• 避免用 clock() 或 gettimeofday() ——它们精度低、可移植性差、且不属 C++ 标准时序接口

循环测试要防编译器优化把代码“优化没了”

写个 for 循环测函数耗时，结果打印出来总是 0μs？大概率是编译器发现你没用返回值、也没副作用，直接把整个循环干掉了。

让计时有意义的几个关键操作：

• 把待测函数的**返回值赋给 volatile 变量**，例如：volatile auto result = my_func();
• 或者用 asm volatile("" ::: "memory"); 插入内存屏障（GCC/Clang）
• Release 模式下测试前，先确认 -O2 或 -O3 没把目标逻辑内联并折叠——可临时加 [[gnu::optimize("O0")]] 属性（GCC）或查看汇编输出
• 单次耗时太短（如纳秒级）？重复执行 N 次再除以 N，但注意别引入循环开销偏差（N ≥ 10000 更稳妥）

Windows 下 QueryPerformanceCounter 精度更高但没必要手动封装

确实，QueryPerformanceCounter 在 Windows 上能提供接近 CPU 周期级的稳定性，比 steady_clock 理论上更准。但现代 MSVC 和 Clang 对 steady_clock 的实现已直接基于 QPC，无需自己调 Win32 API。

除非你遇到这些情况，否则别碰原生 API：

• 需要微秒以下分辨率（如 100ns 量级）且确认硬件支持
• 做实时系统或硬实时性能分析，要求误差绝对低于 1μs
• 正在写跨平台底层库，且明确知道各平台 steady_clock 实现缺陷（极少见）

自己封装 QPC 容易踩坑：频率查询失败、除零、整数溢出、多核 TSC 不同步等问题，得不偿失。