Callgrind 默认不显示可读成员函数名，需加 --demangle=yes；编译须带 -g；多线程需 --separate-threads=yes；虚函数调用开销不可见，Ir 不代表真实耗时。
Callgrind 默认不显示成员函数名，得加 --demangle=yes
Callgrind 输出的符号默认是 C++ mangling 后的乱码，比如 _ZNK3Foo5barEv，根本看不出是哪个类哪个成员函数。不处理这一步，后续所有分析都白搭。
必须显式启用 demangle，否则 callgrind_annotate 或 kcachegrind 都无法还原可读函数名：
valgrind --tool=callgrind --demangle=yes ./myapp- 编译时务必带
-g，否则即使 demangle 成功，也关联不到源码行 - 如果用了
inline或模板实例化过深，部分调用可能仍显示为???，这不是 bug，是符号信息被优化掉了
callgrind_annotate 里怎么识别成员函数调用开销
生成 callgrind.out.PID 后，用 callgrind_annotate 查看文本报告，关键看三列：Ir（指令数）、function、file:line。
成员函数会以 ClassName::MethodName 形式出现（前提是 demangle 开了且符号完整）：
立即学习“C++免费学习笔记（深入）”；
- 若某
MyClass::process()的Ir占比特别高，说明它确实是热点 - 注意区分
MyClass::process()和MyClass::process() [clone .constprop.0]—— 后者是 GCC 编译器内联/常量传播产生的变体，实际是同一逻辑，但 Callgrind 会分开计数 - 静态成员函数和普通成员函数在报告中格式一致，无特殊标记；友元函数则按其定义位置归属到对应文件
多线程下成员函数开销统计容易错乱
Callgrind 默认把所有线程的采样混在一起，如果你的 std::thread 调用了同一个成员函数（比如 Worker::run()），不同线程的调用会被合并统计，看不出哪个线程拖慢了整体。
要分线程观察，必须加参数：
-
--separate-threads=yes：为每个线程生成独立的调用计数，输出中函数名后会带[thread N] - 配合
--dump-instr=yes可导出每条指令级数据，但文件巨大，仅调试极端场景才用 - 注意：开启
--separate-threads后，kcachegrind会自动识别并提供线程切换视图；而callgrind_annotate文本报告不会自动分组，需手动 grep 筛选
虚函数调用开销在 Callgrind 中不可见
Callgrind 统计的是指令执行次数（Ir）和缓存行为，不是运行时开销。虚函数调用本身那一次 vtable 查找（几条指令）几乎不占 Ir，所以你在报告里看不到“虚函数比普通函数慢”这种结论。
真正影响性能的，是虚函数导致的代码无法内联、CPU 分支预测失败、或 cache 局部性变差——这些需要结合 --cache-sim=yes 或 perf 进一步验证：
-
valgrind --tool=callgrind --cache-sim=yes ./myapp会额外输出 D1i、LL miss 等列 - 如果某个虚函数重载频繁调用且
D1mr（一级数据缓存缺失率）异常高，才值得怀疑是虚表跳转引发的 cache 不友好 - 单纯看
Ir排名前几的虚函数，大概率只是业务逻辑重，和“虚”无关
最易被忽略的一点：Callgrind 的 Ir 是模拟指令数，不是真实耗时。一个 Ir 很高的成员函数，如果全是内存密集型操作（比如 memcpy），实际 wall-clock 时间可能远超一个 Ir 低但计算密集的函数。别只盯着排序第一的函数优化，先确认它是不是真正的瓶颈。
