std::chrono::high_resolution_clock 并非真正跨平台高精度，Windows常退化为毫秒级，Linux通常纳秒级；实测应查period::num/den，性能测试优先用steady_clock，微秒测量需duration_cast避免手算，短函数须多次取最小值防噪声。
chrono::high_resolution_clock 真的“高精度”吗？
它不保证跨平台精度一致，Windows 上常退化为 steady_clock（毫秒级），Linux 通常能到纳秒。别直接信文档写的“highest possible resolution”，得实测。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用
std::chrono::high_resolution_clock::period::num和den查真实周期，比如输出1/1000000000表示理论纳秒级，但实际调度、测量开销可能掩盖它 - 性能测试时优先用
std::chrono::steady_clock：单调、无跳变、适合间隔测量，high_resolution_clock反而可能因系统实现不稳定 - 避免在循环内反复调用
now()——每次调用有几十纳秒开销，测短函数会失真
怎么写一个靠谱的微秒级耗时测量？
核心是「单次调用起点和终点 + 类型推导」，别手写单位换算，让 duration_cast 干活。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用
auto start = std::chrono::steady_clock::now();和auto end = std::chrono::steady_clock::now();——auto保留高精度time_point类型，避免隐式截断 - 转微秒用
std::chrono::duration_cast<:chrono::microseconds>(end - start).count()</:chrono::microseconds>，别用/ 1000手算，整数除法会丢精度 - 测小函数务必跑多次取最小值或中位数，单次测量包含 cache 预热、分支预测失败等噪声
为什么测出来的时间总是 0 或波动极大？
不是代码错，是测量对象太轻或环境干扰太强。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
常见错误现象：
- 被测函数执行远快于时钟分辨率（如空循环、简单加法），
end - start为 0 个 tick - 编译器优化把整个待测逻辑干掉了（尤其没副作用的计算），加
volatile或用结果阻止优化 - CPU 频率动态缩放、上下文切换、TLB miss 导致单次结果从 100ns 到 2μs 都可能
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 对极短操作，用
do { /* code */ } while (std::chrono::steady_clock::now() - start 累积多次再算均值 - 强制使用结果：把返回值写入
volatile int sink;，防止编译器优化掉 - Linux 下可临时用
taskset -c 0绑核、sudo cpupower frequency-set -g performance锁频，减少干扰
chrono 在 Release 和 Debug 下结果差十倍正常吗？
非常正常，Debug 模式下 std::vector::push_back 可能带边界检查、迭代器调试钩子，std::string 的 small string 优化也可能被关掉。
关键点：
- 性能测试只在 Release 下做，且确保
-DNDEBUG已定义（禁用 assert）、-O2或-O3开启优化 - Clang/GCC 的
-fno-exceptions和-fno-rtti有时也能挤出几纳秒，尤其虚函数多的场景 - 注意 CMake 默认的
RelWithDebInfo是“带调试信息的 Release”，但可能没开满优化，确认CMAKE_CXX_FLAGS_RELWITHDEBINFO
真正难控的是硬件层：CPU 微码更新、内存频率、甚至主板 BIOS 中的 C-states 设置，都会让同一段代码在不同机器上差出 20%。别只信本地数字，多台机器交叉验证才敢下结论。
