perf是首选：内核级采样、开销低（通常1%-5%）、支持用户/内核空间全栈分析；gprof因插桩扭曲调用行为已基本弃用；valgrind适合深度内存与并发问题诊断。
怎么选对 profiler：gprof、perf、valgrind 用哪个
Linux 下 C++ 性能调优，gprof 基本可以放弃了——它依赖插桩，会严重扭曲内联、虚函数、模板展开行为，测出来的 main 占比常高得离谱，但实际热点根本不在那儿。perf 是首选：内核级采样，开销低（通常 libunwind 或 dwarf 做准确的栈回溯。valgrind --tool=callgrind 适合找细粒度调用频次和指令数，但运行慢 20–50 倍，只应在 perf 定位到模块后做深挖。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 先跑
perf record -g -e cycles,instructions,cache-misses ./myapp，再用perf report -g folded看火焰图数据 - 如果程序启动快、退出快（比如 CLI 工具），加
-F 99提高采样频率，避免漏掉短生命周期函数 - 编译时务必加
-g -O2（不是-O3），-O3可能让内联过度，perf把多个逻辑折叠成一个符号，反而看不清真实调用链
火焰图里看到 std::vector::push_back 占高，真要改代码吗
不一定。std::vector::push_back 在火焰图里显眼，大概率是它触发了内存重分配（reallocate），真正瓶颈在 operator new 和 memcpy 上。这时候看 perf script 输出里是否紧跟着 __GI___libc_malloc 或 __memmove_avx_unaligned_erms —— 如果是，说明 vector 频繁扩容拷贝了大量数据。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 检查所有 vector 创建点，用
reserve()预估容量，尤其在循环前或构造函数中 - 若 vector 存的是小对象（如
int、std::pair），确认没意外发生 move/copy 语义误用（比如传值捕获 lambda 导致隐式拷贝） - 用
perf probe打点验证：perf probe 'std::vector::push_back' && perf record -e probe_std__vector__push_back ./myapp，看调用频次是否异常
为什么 std::sort 在 perf 里显示为 ?? 或地址片段
这是符号缺失的典型表现。常见原因有两个：一是编译时没加 -g，二是 std::sort 被完全内联进调用者函数（比如你写了 std::sort(v.begin(), v.end())，而编译器把它展开了），perf 采样到的 PC 指针落在调用者代码段里，但调试信息没把内联上下文映射回来。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 编译加
-g -frecord-gcc-switches，确保 dwarf 信息完整；链接时别加--strip-all - 临时禁用内联排查：
g++ -O2 -g -fno-inline-functions-called-once，再跑 perf，看std::sort是否可识别 - 更可靠的方式是用
perf annotate定位具体汇编行：perf annotate --symbol=_ZSt6sort...（用nm -C a.out | grep sort先找 mangled 名）
多线程程序用 perf 看不到某线程的栈帧
perf record 默认只记录主线程，其他线程的采样会被丢弃，除非显式开启系统范围采集或指定线程 PID。另外，如果线程使用了 pthread_create 但没调用 pthread_setname_np，perf report 里可能只显示数字 tid，难以关联业务逻辑。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 采集时加
-a（system-wide）或-p $(pidof myapp)，后者更安全；若知道目标线程 tid，可用-t TID1,TID2 - 程序启动后，尽快在关键线程里调用
pthread_setname_np(pthread_self(), "worker-1")，perf report就能按名字过滤：perf report --comm=worker-1 - 注意：
perf对 futex 等内核同步原语的采样有延迟，若看到大量futex_wait_queue_me，优先查锁竞争，而不是函数本身慢
真正难的不是跑出火焰图，而是区分「采样偏差」和「真实热点」——比如 std::string::c_str() 看似耗时高，实际可能是它前面那个正则匹配触发了反复内存分配，而 c_str 只是最后被采样到的“替罪羊”。盯住调用栈上游三到四层，比死磕最顶上那个函数名有用得多。
