cachegrind不直接输出热点，需用cg_annotate解析：关键列为ir（指令数，反映cpu热点）、i1mr和llmr（缓存未命中数，反映数据局部性瓶颈），高llmr行常对应大数组写、哈希遍历等缓存抖动源。
用 cachegrind 生成带缓存统计的调用报告
直接运行 valgrind --tool=cachegrind ./myapp 不会立刻看到“热点”，它只把数据写进默认文件 cachegrind.out.<pid></pid>。必须配合 cachegrind_annotate 或 cg_annotate（二者等价）才能解析出可读结果。不跑这一步，你拿到的只是二进制痕迹，不是代码段分析。
cachegrind_annotate 输出里哪几列真正反映“热点”
执行 cachegrind_annotate cachegrind.out.12345 后，关键看三列：
-
Ir：指令读取次数 —— 高值说明该行反复执行，是 CPU 时间热点 -
I1mr和LLmr：一级指令缓存和末级缓存未命中率 —— 高未命中率（比如 >1% 的LLmr）说明该段代码触发大量缓存抖动，可能因数据局部性差或循环体过大 -
file:line列右侧的数字：按Ir降序排列，顶部就是最热的源码位置
为什么函数内联或模板展开会让 cachegrind 报告失真
cachegrind 统计的是机器指令流，不是抽象函数边界。以下情况会导致归因混乱：
- 编译器开启
-O2后，小函数被内联，cachegrind_annotate显示的“高Ir行”可能属于调用者而非原函数体 - STL 容器（如
std::vector::push_back）在头文件中全量展开，热点常落在/usr/include/c++/.../stl_vector.h某行，而非你的.cpp文件 - 没有调试信息（
-g）时，cachegrind_annotate只能按汇编地址分组，无法关联到源码行
想快速定位循环体或计算密集段？加 --cache-sim=yes 并过滤 LLmr
默认 cachegrind 只做指令统计；启用缓存模拟后，才能看出数据访问瓶颈：
- 运行命令改为：
valgrind --tool=cachegrind --cache-sim=yes ./myapp - 然后用
cachegrind_annotate --show=LLmr cachegrind.out.12345 | head -20直接筛出末级缓存未命中最高的 20 行 - 这类行往往对应：大数组连续写（但 stride 跨 cache line）、哈希表冲突链遍历、或未对齐的结构体字段访问
真正难处理的不是“哪行指令多”，而是“哪块数据布局让缓存反复扑空”——这需要把 LLmr 数值和源码中的内存访问模式对照着看，而不是只盯着 Ir 排序。
