CPU性能分析工具介绍

做性能优化，最怕的是什么？靠猜。猜哪里慢，猜哪个函数耗CPU，猜内存怎么泄露的。我以前也这样干过，结果优化半天，性能一点没提升，还引入了新bug。嗯，后来学乖了：先测量，再优化。这就是性能分析工具存在的意义。

这一章，我就聊聊常用的CPU性能分析工具。不是罗列所有工具，而是帮你建立个选择框架——什么场景用哪个，怎么用最快拿到结果。

为什么需要性能分析工具

说白了，没有数据就没有方向。你写了一个SDK接入模块，跑起来感觉慢，但慢在哪？

• 是某个循环计算量太大？
• 还是频繁的系统调用？
• 又或者是内存分配/释放太多次？

凭经验猜，通常错一半。我有个亲身教训：有一次优化一个图像处理SDK，直觉认为是像素级循环慢，结果用perf一测，发现60%的CPU时间花在反复申请临时缓冲区上。与其优化循环，不如改用内存池。你看，工具一跑，方向就变了。

常用CPU性能分析工具概览

目前主流的工具，大致分三类：采样型、插桩型和追踪型。我整理了一个对比表，方便你快速取舍。

我个人习惯：先用perf stat看宏观数据，再用perf record看热点函数。如果怀疑内存相关，才搬出Valgrind。没有必要一上来就把最重的工具挂上。

perf——Linux性能分析利器

perf是Linux内核自带的分析器，依赖硬件PMU（Performance Monitoring Unit）。你不需要装额外软件，大部分发行版都自带。它的核心用法就几个命令。

# 统计整体指标（CPU利用率、上下文切换等）
perf stat ./your_program

# 记录采样数据
perf record -g ./your_program

# 报告分析结果（显示热点函数）
perf report -g

举个例子。我以前优化一个网络SDK的接收线程，代码看着没问题，但CPU跑满。执行perf stat后，发现context-switches高达每秒几万次。这不对劲。然后perf record -g采样，报告一看，__schedule调用占了20%，顺着调用链发现是线程里每读一个包就sleep(0)。改成无锁环形缓冲区后，上下文切换降到几百次每秒。

gprof与Valgrind的适用场景

gprof是老牌工具，简单直接。但需要编译时加-pg选项。用法：

gcc -pg -o myapp myapp.c
./myapp
gprof myapp gmon.out > analysis.txt

它会告诉你每个函数被调了多少次，每次平均耗时。适合逻辑不复杂的程序。但要注意：gprof在多线程程序里表现不好，采样粒度也粗。

Valgrind下的Callgrind就不一样了。它能模拟CPU缓存，给出每条指令级别的延迟。代价呢？程序运行速度会慢20-30倍。所以我只在优化到最后阶段，或者怀疑缓存伪共享、分支预测错误时才用它。

如何选择合适的工具

这里我给一个决策流程图，能帮你快速定位该用哪个工具。

看到这个图，你会明白：大多数场景从perf入门就够了。只有当你确认是内存缓存问题或需要微观细节时，才向下深入。

实战案例：快速定位CPU瓶颈

说个真实例子。去年我优化一个视频编解码SDK，发现编码时CPU负荷飙到90%。用perf stat一看：

perf stat -e cycles,instructions,cache-misses,cache-references ./encoder --input test.yuv

   5,324,567,890 cycles
   4,123,456,789 instructions
   2,345,678 cache-misses
  12,345,678 cache-references

指令每周期数IPC才0.77，算正常范围。但cache-misses比例高达19%——这就是问题。然后：

perf record -e cache-misses -g ./encoder ...
perf report -g

报告显示，最高频的cache-miss发生在motion_search()函数内部的一个循环里，访问的是参考帧的相邻宏块数据。原因是宏块数据在内存里跳来跳去，导致缓存行不断被踢出。

解决方法也很简单：把参考帧按宏块顺序重排，或者采用tile访问模式。改完之后cache-miss降到5%以下，编码速度提升了40%。

好了，这一章就讲这些。工具只是手段，分析思路才是核心。记住：先测试，再动手，少走弯路。