callgrind主要用于分析函数调用开销和执行热点，统计调用次数、指令周期、子函数耗时及调用链深度；其核心差异在于动态二进制插桩，无需重编译，支持内联函数与多线程调用栈分离，并可模拟缓存行为。
Callgrind 主要用来分析函数调用开销和执行热点
它不是看内存泄漏，也不是查线程竞争——那是 memcheck 和 helgrind 的事。Callgrind 的核心任务是：统计每个函数被调用了多少次、每次耗多少指令周期、子函数占了多少时间、调用链路有多深。它生成的是「谁被谁调、调了多少次、花了多少 CPU 时间」的明细账。
为什么不能直接用 gprof？Callgrind 的关键差异在哪
gprof 依赖编译时插桩（-pg），会改变程序行为，且不支持内联函数、无法处理多线程调用栈交叉；而 callgrind 是动态二进制插桩，在运行时模拟 CPU 指令流，不修改源码也不要求重编译（但加 -g 能关联源码行号）。它还能模拟 L1/L2 cache 行为（加 --cache-sim=yes），这是 gprof 完全做不到的。
- 没加
-g编译：报告里只有函数名，看不到具体哪一行耗时 - 开了
--separate-threads=yes：才能区分不同线程的调用路径，否则所有线程混在一起统计 - 默认只统计用户代码：系统调用（如
malloc、write）默认被忽略，需加--collect-systime=yes才计入
callgrind_annotate 输出里哪些数字真正值得盯
执行 callgrind_annotate callgrind.out.12345 后，最该关注三列：
-
Ir（Instruction Read）：CPU 执行的指令条数 —— 这是 Callgrind 最可靠的指标，不受系统调度干扰 -
Dr/Dw（Data read/write）：缓存读写次数，配合--cache-sim=yes可定位 cache miss 高发点 -
file:function:line列中的百分比：不是“总耗时占比”，而是「该行贡献的指令数占整个 profile 的比例」
注意：callgrind_annotate 默认按 Ir 排序，但如果你关心 cache 行为，得加 --sort=Dr 或 --sort=Dw 才能看到数据访问热点。
抛异常这种操作，Callgrind 能看出多大开销
可以，而且很准。C++ 异常抛出（throw）不是普通函数调用，它要展开栈、查找 catch 块、析构局部对象——这些都会被 Callgrind 记为大量指令。实测中，一次 throw myException() 在未优化构建下可能消耗 10k+ Ir，而等价的状态码返回（return -1）通常不到 10 Ir。但要注意：这个差距在 Release 编译 + 异常禁用（-fno-exceptions）后就不存在了，Callgrind 报告也会大幅缩水。
容易被忽略的一点是：如果程序里 try 块很多但实际从不 throw，Callgrind 并不会额外计费——它只对真实发生的指令计数，不是对语法结构做静态分析。
