最直接可控的函数耗时测量方式是用 std::chrono::steady_clock 手动打点并显式转换单位，推荐封装为 RAII 计时器配合宏自动管理生命周期，再聚合统计至结构化报告。
用 std::chrono 手动打点测单个函数耗时
最直接、可控性最强的方式就是对关键函数或代码段插入起止时间戳。别依赖全局 profiler 工具——它们容易漏掉你真正想盯的细粒度逻辑。
常见错误是只测 std::chrono::steady_clock::now() 但没注意返回值类型，导致减法出错或隐式转换丢失精度：
- 必须用同一时钟类型（推荐
std::chrono::steady_clock，不受系统时间调整影响） - 差值要用
std::chrono::duration_cast显式转成你需要的单位（如std::chrono::microseconds），不能直接.count()后强转 - 避免把时间测量逻辑和业务逻辑耦合太紧；封装成 RAII 类（比如
ScopedTimer）更安全
示例：
auto start = std::chrono::steady_clock::now(); do_something_heavy(); auto end = std::chrono::steady_clock::now(); auto us = std::chrono::duration_cast<std::chrono::microseconds>(end - start).count(); std::cout << "do_something_heavy: " << us << " μs\n";
用宏 + RAII 自动记录作用域耗时
手动写 start/end 容易漏、难维护，尤其在多分支或异常路径下。用宏包裹 RAII 计时器能保证进出自动记录，且支持命名标识。
立即学习“C++免费学习笔记（深入）”；
关键点在于：RAII 对象生命周期必须严格绑定到作用域，析构时才触发日志；宏要展开成带唯一标识符的变量名，避免嵌套作用域重名冲突。
- 宏定义里用
__COUNTER__或__LINE__生成局部变量名（__FILE__太长，不推荐） - 计时器类的构造函数记录起点，析构函数算差值并输出（建议输出到
std::cerr，避免和正常输出混在一起） - 不要在计时器里做格式化字符串拼接——开销大；先存原始
microseconds::count()，最后统一打印
典型用法：
#define SCOPED_TIMER(name) ScopedTimer timer##__COUNTER__(name)
// …
void process_frame() {
SCOPED_TIMER("process_frame");
decode();
filter();
encode();
}
聚合多个耗时数据到结构化报告
光有单次耗时没意义，真实分析需要统计分布：平均值、P95、最大值、调用次数。硬编码 printf 不可扩展，得建轻量级计时器注册表。
核心结构是一个全局 std::unordered_map<std::string, TimerStat>，每次进入同一名字的 SCOPED_TIMER 就往对应项累加耗时和计数。
- 用
std::atomic保护共享计数器（尤其多线程场景下），但注意atomic<int64_t>比atomic<long long>更稳妥 - 避免在 hot path 上做 map 查找——提前缓存
TimerStat*指针，首次访问后复用 - 报告输出时机很重要：不能每帧都 dump，建议在程序退出前或按固定周期（如每 100 帧）汇总一次
输出示例（文本格式即可，无需 JSON）：
decode: calls=1247, avg=842μs, p95=1120μs, max=3890μs filter: calls=1247, avg=210μs, p95=290μs, max=760μs encode: calls=1247, avg=1560μs, p95=1980μs, max=4200μs
注意编译器优化和 CPU 频率干扰
测出来的数字不准？大概率是编译器把被测代码优化掉了，或者 CPU 动态降频拉低了单次执行速度。
- 确保测试时关掉
-O0（太慢）、也别用-O3（可能内联/消除整个块）；-O2是较合理基线 - 禁用编译器对计时代码本身的优化：用
volatile强制读写，或调用asm volatile("" ::: "memory")插内存屏障 - Linux 下可用
sudo cpupower frequency-set -g performance锁定 CPU 频率；Windows 可设电源计划为“高性能” - 单次测量波动大？至少跑 10 次取中位数，别信第一次结果
最常被忽略的是：没确认被测代码是否真的执行了——比如条件分支没进、输入数据为空、缓存命中导致耗时极低。先加个 std::cerr << "hit!" 确认逻辑走通，再测时。
