17370845950

gprof编译必须加-pg且禁用-O2以上优化，因高阶优化会内联函数导致统计失真；perf需-g或--call-graph dwarf开启调用栈采样，二者采样逻辑本质不同：gprof插桩，perf硬件采样。

gprof 编译时必须加 -pg，且不能用 -O2 以上优化

gprof 依赖编译器在函数入口/出口插入计数桩（instrumentation），-pg 是强制开关。但高阶优化（如 -O2、-O3）可能内联函数、删减调用栈，导致 gprof 统计失真甚至崩溃。

• 正确编译命令：g++ -pg -O1 -g main.cpp -o main
• 错误示范：g++ -pg -O3 main.cpp -o main → 调用图断裂，gprof main 显示大量
• -g 不是可选：没有调试信息，gprof 无法把地址映射回函数名

perf record -g 要用 -g 或 --call-graph dwarf 才能看调用栈

默认 perf record 只采样当前指令指针，看不到函数调用关系。必须显式开启 call graph 支持，否则 perf report 里全是平铺的符号，没法定位热点路径。

• 推荐命令：perf record -g -e cycles:u ./main（用户态周期采样）
• 若遇到 failed to parse /proc/kallsyms 或栈展开失败，换用：perf record --call-graph dwarf -e cycles:u ./main
• 注意：dwarf 模式依赖 -g 编译，且比 fp（frame pointer）模式稍慢，但兼容性更好（尤其启用 -fno-omit-frame-pointer 时）

gprof 输出里 flat profile 看耗时，call graph 看传播路径

gprof main gmon.out 默认输出两块：上面是各函数自身耗时（self），下面是调用关系（children + called）。别只盯着 % time 最高的函数 —— 它可能只是被频繁调用的“工具函数”，真正瓶颈常藏在 children 时间占比大的父函数里。

index % time    self  children    called     name
[2]    92.1    0.00    0.46       1/1           main [2]
               0.46    0.00       1/1           heavy_calculation [3]

• heavy_calculation 占了 main 的全部子耗时（0.46s），但它自己 self 是 0.46s → 瓶颈就在它内部
• 如果某函数 self 很小但 children 很大，说明它只是中转站，得继续往下钻
• called 列为 1/1 表示被调用 1 次，第一个数字是实际调用次数（比如 100/1 就是被 main 调了 100 次）

perf report 用 ↑↓←→ 导航，按 Enter 进入调用栈，q 退出

终端里 perf report 是交互式界面，不是静态文本。很多人直接扫一眼就关掉，其实关键信息藏在展开的调用树里。

• 高亮某行后按 Enter，会显示该函数的完整调用链（从 main 开始逐层向下）
• 按 → 可展开汇编视图（需带 -g 和 -g 编译），看到哪条指令最热（比如某次 mov 后卡住，或 div 指令频繁出现）
• 按 / 可搜索函数名；按 ? 查快捷键 —— 别跳过这步，很多性能拐点靠 → 展开才看得见

gprof 和 perf 的根本差异不在命令行参数，而在采样逻辑：gprof 是插桩（修改代码行为），perf 是硬件事件采样（尽量无侵入）。所以对短生命周期程序、高频系统调用场景，perf 更可靠；而 gprof 在需要精确函数级时间分配时仍有价值 —— 前提是你记得关掉激进优化。