callgrind_annotate输出首列数字即函数（或指令）被调用的总次数，对函数入口行基本等价于函数调用次数；需配合--dump-instr=yes和--collect-jumps=yes才能准确统计调用关系。
callgrind_annotate 怎么看函数调用次数
直接看 callgrind_annotate 输出里每行开头的数字，就是该行对应函数（或指令）被调用的**总次数**。这个数不是“进入函数的次数”，而是该行汇编指令被执行的次数；对函数入口行来说，它基本等价于函数被调用的次数。
关键点：调用次数统计依赖于 --dump-instr=yes 和 --collect-jumps=yes 等选项是否开启，但默认 callgrind 就会记录函数调用事件，callgrind_annotate 默认按“调用次数”排序并展示。
-
callgrind_annotate输出中，第一列是“被调用次数”，第二列是“指令执行次数”，第三列才是源码/函数名 - 如果某函数内联了，它不会单独出现在列表里；想看到内联函数调用，得加
-fno-inline编译 - 注意区分
fun()@plt（PLT 跳转桩）和真正的fun—— 前者是动态链接跳转，后者才是实际函数体，调用次数应以后者为准
valgrind --tool=callgrind 运行时必须加哪些参数
只跑 valgrind --tool=callgrind ./a.out 是能出数据，但默认不记录调用关系，也看不到函数间调用频次。要准确统计“谁调用了谁、调了多少次”，至少要加这两个：
-
--dump-instr=yes：启用指令级计数（让callgrind_annotate能分指令显示调用频次） -
--collect-jumps=yes：收集跳转信息（这是构建调用图的基础，否则callgrind_control或kcachegrind看不到调用边） - 可选但强烈建议：
--cache-sim=yes（顺便看缓存行为）、--branch-sim=yes（分支预测开销），不过它们不影响调用次数本身
漏掉 --collect-jumps=yes，你用 kcachegrind 打开 callgrind.out.* 文件时，“Callers”和“Callees”标签页就是空的——这不是工具坏了，是根本没采集。
为什么 callgrind_annotate 显示的调用次数和代码里 for 循环次数对不上
常见原因不是工具不准，而是你忽略了 C++ 异常、STL 内部调用、编译器优化这几层干扰：
- 一个
throw可能触发几十次栈展开相关的函数调用（比如__cxa_throw、__gxx_personality_v0），这些都会被计入总调用次数，但不在你的源码循环里 - STL 容器操作（如
std::vector::push_back）内部有分支判断、内存检查、构造/析构调用，每次调用都可能展开成多个底层函数调用 - 编译器开启了
-O2以上，可能把小函数全内联了，导致你写的函数名在输出里消失，调用次数被合并到调用方里 -
callgrind统计的是“指令执行次数”，不是“C++ 语句执行次数”。比如for (int i = 0; i 中，<code>i++和i 这两条指令各自执行了 N 次，也会被分别计数
用 kcachegrind 查看调用次数比命令行更直观吗
是的，而且不只是“更直观”——kcachegrind 是唯一能交互式查看“调用上下文”的方式。比如你想知道 fun2_throwError 是被哪个函数在第几行调用了 100000 次，callgrind_annotate 只能给你一个总数；而 kcachegrind 点开该函数 → 切到 “Callers” 标签页 → 点击具体 caller 行，右侧立刻显示源码位置和精确调用次数。
注意：kcachegrind 不是必须的，但它依赖 callgrind 输出的完整调用图数据。如果你只想要纯命令行方案，可以用：
callgrind_annotate --auto=yes --inclusive=yes callgrind.out.12345
其中 --inclusive=yes 会让它显示“包含子调用”的累计次数，更接近你直觉里的“函数耗时占比”。但调用路径细节，还是得靠图形界面。
