最可靠方法是用 std::chrono::high_resolution_clock 测单次运行时间，因其跨平台、高精度、避免编译器优化干扰，且需循环多次取中位数、禁用相关优化并统一纳秒/微秒单位保存原始值。
用 std::chrono 测单次运行时间最可靠
Windows 上用 GetTickCount64 或 Linux 用 clock_gettime(CLOCK_MONOTONIC, ...) 虽然快，但跨平台难、精度不一致、还容易被系统调度假影响。C++11 起 std::chrono 是唯一推荐路径——它底层调用的就是这些高精度时钟，但封装掉了平台差异。
常见错误是用 std::clock()：它测的是 CPU 时间，多线程下不准；而且在某些 libc 实现里分辨率只有 10ms，跑不到 10ms 的函数根本测不出差别。
实操建议：
- 始终用
std::chrono::high_resolution_clock（别用steady_clock或system_clock，前者可能不真“高精度”，后者带时区偏移） - 起止时间必须用同一时钟类型，否则
duration_cast可能静默截断 - 测短函数务必循环多次再除以次数，单次调用的测量误差常比函数本身还大
auto start = std::chrono::high_resolution_clock::now(); do_work(); auto end = std::chrono::high_resolution_clock::now(); auto us = std::chrono::duration_cast<std::chrono::microseconds>(end - start).count();
避免编译器优化把待测代码“优化掉”
你看到的 us == 0，大概率不是函数快，是编译器发现结果没被用，直接删了整段逻辑。尤其开 -O2 后，int x = fib(10); 如果 x 后面没出现，fib 就不会执行。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 把计算结果强制输出到 volatile 变量：
volatile int sink = result;，或用asm volatile("" :: "r"(result) : "memory"); - 不要测空循环：
for(int i=0; i<N; ++i) {}会被优化成i = N，实际耗时接近 0 - Release 模式下测试才有意义，但必须关掉与待测逻辑相关的优化（比如加
#pragma GCC optimize("O0")包围函数）
多轮采样才能看出真实性能波动
一次测量值毫无参考价值：CPU 频率动态调整、TLB 缓存未热、内存页未分配、后台进程抢占……都会让结果差出 2 倍以上。有人测出 “优化后变慢”，其实是第一次跑 cache miss 太多。
实操建议：
- 至少跑 5–10 轮，取中位数而非平均值（平均值会被异常值拉偏）
- 每轮之间用
std::this_thread::sleep_for(1ms)隔开，减少连续调度干扰 - 记录最小值和最大值，如果两者差 > 20%，说明环境不稳定，需检查是否有其他进程吃 CPU 或内存
注意 std::chrono::duration_cast 的截断行为
很多人写 duration_cast<milliseconds>(d).count() 看到结果是 0，就以为函数很快——其实可能是 999 微秒，被截断成 0 毫秒。更糟的是，用 round<milliseconds> 或 ceil 会引入额外浮点运算开销，污染测量结果。
实操建议：
- 统一用微秒或纳秒单位保存原始值，后期再换算显示，避免中间截断
- 不要用
auto t = duration_cast<microseconds>(d).count();再传给别的函数——count()返回long long，但不同平台可能有符号差异 - 如果必须转整数，用
duration_cast<microseconds>(d).count()，别漏掉.count()，否则得到的是duration对象，不能直接打印
测准一次不难，难的是让每次测量都可比。最常被忽略的是：没清 CPU 缓存、没绑核、没关 turbo boost、甚至没关笔记本的节能模式——这些都会让两次相同代码跑出完全不同的数字。
