第2章性能剖析工具链

2、性能剖析工具链：Linux Perf、gprof、Valgrind、火焰图工具介绍与选型

做ADAS系统性能优化，手里没几把趁手的工具，那真是寸步难行。我这些年跟各种性能瓶颈打交道，从CPU飙到100%到内存泄漏导致系统重启，踩过的坑不少。今天我就把这几个最常用的工具——Linux Perf、gprof、Valgrind、火焰图，掰开揉碎了讲讲。

说白了，选工具就像选螺丝刀。你不能拿一字螺丝刀去拧十字螺丝。每个工具都有自己的脾气和适用场景。我们先看看它们各自擅长什么。

Linux Perf是我用得最多的工具。它直接跟内核的PMU（性能监控单元）打交道，开销极低。你想想看，在ADAS这种实时性要求极高的系统里，你加个监控工具就把系统拖慢了，那还玩什么？

Perf能干什么？它能告诉你CPU周期花在哪了，缓存命中率如何，分支预测失败了多少次。这些底层数据，是定位微架构级瓶颈的关键。

核心用法：

# 采样CPU周期，持续10秒
perf record -e cycles -a -g -- sleep 10

# 生成报告
perf report -g graph

我个人习惯先用perf top看一眼全局。就像医生先量体温，看看有没有发烧。如果某个函数占CPU超过20%，那基本就是重点怀疑对象了。

我的经验： 在ADAS的感知模块中，我曾经用Perf发现图像预处理函数占用了40%的CPU。后来发现是内存拷贝太频繁，改成零拷贝后，帧率直接翻倍。

gprof是个老家伙了，但它有个独特优势——能告诉你函数调用了多少次，以及每次调用的平均耗时。Perf虽然也能看调用图，但gprof的统计方式更直观。

不过要注意，gprof需要编译时加-pg选项。这意味着你得重新编译代码。我在项目中遇到过一个问题：加了-pg后，编译器优化级别被降低，导致性能数据跟线上环境有偏差。

避坑指南： 我曾经因为gprof的采样数据跟实际性能对不上，排查了整整两天。后来发现是-pg选项影响了内联函数。所以，gprof更适合做定性分析，别太迷信它的绝对值。

// 编译时加入 -pg 选项
gcc -pg -O2 my_program.c -o my_program

// 运行程序，生成 gmon.out
./my_program

// 分析结果
gprof my_program gmon.out > report.txt

Valgrind不是用来做CPU性能分析的，它是内存问题的克星。内存泄漏、越界访问、使用未初始化内存……这些问题在ADAS系统里是致命的。你想想，一个车在路上跑着，突然因为内存泄漏导致系统OOM（内存耗尽），那后果是什么？

Valgrind的memcheck工具是我最常用的。它会在程序运行时插入检查代码，所以运行速度会慢10-20倍。嗯，这里要注意：千万别在生产环境上跑Valgrind，那会直接把系统拖死。

典型用法：

# 检查内存泄漏
valgrind --leak-check=full ./my_adas_app

# 检查越界访问
valgrind --tool=memcheck ./my_adas_app

我记得有一次，ADAS的决策模块每隔几小时就会崩溃一次。用Valgrind一跑，发现是一个全局变量被多个线程同时写，导致内存损坏。这种问题，光靠看代码是很难发现的。

火焰图不是工具，而是一种数据可视化方式。它把Perf采集的堆栈数据，画成一张像火焰一样的图。横轴是采样数量，纵轴是调用栈深度。哪个函数占的CPU多，它的“火焰”就宽。

我个人觉得，火焰图最大的价值在于——它能让你一眼看出“热点”在哪。你不需要一行行看报告，扫一眼图就知道问题在哪。

生成火焰图的步骤：

为什么采样频率用99Hz而不是100Hz？因为100Hz容易跟系统时钟产生共振，导致采样偏差。这是个小技巧，但很实用。

好了，四个工具都介绍完了。那到底什么时候用哪个？我总结了一张表，你直接照着用就行。

重要提醒： 别指望一个工具解决所有问题。我见过有人用Valgrind去查CPU性能问题，结果等了半小时还没跑完。工具选错了，效率就是负数。

最后说一句，这些工具只是辅助。真正定位瓶颈，靠的是你对系统架构的理解。工具告诉你“哪里慢”，你得自己想“为什么慢”。比如Perf告诉你某个函数占CPU高，你得去分析：是算法复杂度高？是缓存不友好？还是锁竞争？

嗯，工具是死的，人是活的。多练多用，慢慢你就有感觉了。