callgrind 百分比表示该行执行的cpu指令数占程序总指令数的比例，反映计算资源消耗而非时间或内存；需结合调用次数（called）和指令数（ir）综合判断热点，注意排除plt、跳转等噪声。
Callgrind 输出的百分比是相对指令数占比
Valgrind 的 callgrind_annotate 或 callgrind_annotate --auto=yes 报告中，每行开头的百分比（如 23.45%）表示该函数/源码行所执行的 **CPU 指令数占整个程序总指令数的比例**，不是时间、内存或调用次数的占比。它反映的是“程序花多少计算资源在这一行上”，和 CPU 热点强相关。
这个值由 Callgrind 在运行时插桩统计每条 VEX IR 指令的执行次数推导而来，最终归一化为百分比。它不等价于 wall-clock 时间（尤其在 I/O 或 sleep 占比高时），但对纯计算密集型代码非常有参考价值。
百分比数值本身不绝对，要看上下文对比
单独看某一行 12.8% 没意义，关键看它是否显著高于其他函数或是否集中在不该热点的位置。常见判断逻辑：
- 同一函数内，某几行占比突增（比如循环体内部某次 malloc 或 string::append 占了函数 70%），说明这里是优化突破口
- 标准库函数（如
std::vector::push_back、malloc、memcpy）占比异常高，往往暗示频繁小对象分配或低效拷贝 - 模板实例化函数（如
std::__cxx11::basic_string<char>::_M_construct</char>）反复出现且总和高，提示字符串操作可能是瓶颈 - 百分比总和不到 100% 是正常的——Callgrind 不统计内核态、信号处理、部分系统调用及 Valgrind 自身开销
别被“高百分比”误导：注意 --collect-jumps 和 --skip-plt
默认情况下，Callgrind 会统计所有指令，包括 PLT 跳转、动态链接器 stub、甚至一些无关的寄存器保存指令，这会让百分比失真。真实关注点应是业务逻辑层：
- 加
--collect-jumps=no关闭跳转统计，减少噪声 - 加
--skip-plt=yes跳过 PLT 表函数（如printf@plt），让占比更聚焦你自己的代码 - 若分析 C++ 异常抛出开销，必须配合
--trace-children=no避免子进程干扰，否则throw相关函数的百分比会被稀释 - 用
--dump-instr=yes+callgrind_annotate --auto=yes可看到汇编级指令分布，验证高百分比是否真来自预期逻辑
百分比和调用次数要交叉看
Callgrind 报告里除了百分比，还有 called 列（调用次数）和 Ir 列（指令数）。三者关系是：Ir ≈ 百分比 × 总指令数；而 called 告诉你是不是“高频低耗”或“低频高耗”：
- 某函数
called=1但25.6%→ 单次调用极重（比如加载大模型权重），优先看它内部 - 某函数
called=100000且18.2%→ 循环体内热点，适合展开、缓存局部性优化 -
called=0但有百分比？说明是 inline 函数被摊入调用方，需结合-g -O0编译或--read-var-info=yes查源码映射
真正卡住性能的，往往是那个“调用不多但单次吃掉 20% 指令”的函数，而不是调用百万次只占 0.1% 的简单 getter —— 百分比必须和调用频次一起读。
