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 在需要精确函数级时间分配时仍有价值 —— 前提是你记得关掉激进优化。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
