你以为 Rust 很快就不用管性能了？今天三套工具把「猜瓶颈」彻底变成了「看见瓶颈」

Rust 跑得快，不代表没有坑。borrowing 没问题，不代表内存没问题。分配没泄漏，不代表没浪费——这件事，今天被三套工具彻底拆开了。

**配 Rust 配了三年，所有人都告诉你 Rust 快、安全、不用管 GC。但现实是：**

– 解析 JSON 跑 2.5 秒，你以为是算法烂，其实根子在 to_lowercase 每次都在 new String
– 跑了 48 小时内存 3GB，你以为有泄漏，其实是某个 Vec 迭代完还在握着引用
– Lighthouse 红一片，你以为是 CSS 问题，其实是某个循环在反复 allocate

borrowing checker 只管「对不对」，不管「省不省」。性能瓶颈藏在 call stack 里，不藏在代码逻辑里——这件事，Rust 的三套 profiling 工具今天全给你看见了。

—

## 第一套：CPU 采样——perf 和 samply

**做什么：** 采样 call stack，告诉你时间都花在了哪个函数的哪一行。

perf 是 Linux 内核自带的采样器，直接读 CPU 计数器，不需要改一行代码：

cargo build --release
perf record -g ./target/release/my_program
perf report

采样结果长这样——按占用时间排序，最上面的就是你要打的地方。

samply 是更现代的跨平台方案（macOS / Linux / Windows），输出直接进 Firefox Profiler 的交互界面：

cargo install samply
samply record ./target/release/my_program
# 自动打开浏览器，火力图直接高亮热点

采样是什么原理？说人话：程序跑着跑着，profiler 强制把它停一下，问”你刚才在哪一行”，停一万次，统计哪个位置出现次数最多。统计方法，误差可控——某个函数出现 5 次，误差 ±45%；出现 100 次，误差 ±10%。采样时间设长一点，比提高频率更准。

三个工具横评：**perf** Linux 最强但需要 sudo 配内核参数；**samply** 跨平台最顺，macOS 装一个 cargo install 就够；**flamegraph** 生成 SVG 可视化，CI 里跑最合适。

—

## 第二套：内存分析——DHAT

**做什么：** 追踪堆分配，告诉你谁在吃内存，谁在泄漏。

dhat 是 Rust 官方出品的堆分析器，接入全局分配器，全自动追踪，不需要侵入业务代码：

# Cargo.toml
[dependencies]
dhat = { version = "0.3", optional = true }

[features]
dhat-heap = ["dhat"]

# main.rs
#[cfg(feature = "dhat-heap")]
#[global_allocator]
static ALLOC: dhat::Alloc = dhat::Alloc;

fn main() {
    #[cfg(feature = "dhat-heap")]
    let _profiler = dhat::Profiler::new_heap();
    // 业务代码跑在这里
}

cargo run --release --features dhat-heap
# 程序结束后，当前目录生成 dhat-heap.json
# 用浏览器打开 https://nnethercote.github.io/dh_view/dh_view.html 加载分析

dhat 的核心指标有三个：**Total** 是整段执行的总分配量；**At t-gmax** 是峰值时刻谁在占用内存；**At t-end** 是程序退出时还有多少没释放——这个数字不归零，就是泄漏。

看哪个 column？**Live bytes**。Allocation count 高但 live bytes 是零，说明对象在快速创建销毁，通常不是问题。Live bytes 很高，说明有东西在握着内存不放手——那才是你要修的。

dhat 的优势：跨平台（perf/massif 只支持 Linux），overhead 小，输出是纯 Web 页面。不支持追踪内存访问，但分配热点足够你找到大多数问题了。

真实案例：写了一个 JSON 解析器，48 小时后内存爬到 3GB。borrowing checker 全绿，ownership 全对，但内存就是不降。用 dhat 一看，发现某个 Vec 在迭代完之后还在被父级结构握着引用——这事儿 borrowing checker 根本管不着。

—

## 第三套：火焰图——cargo-flamegraph

**做什么：** 生成 SVG 火焰图，把整个 call stack 铺开，让你一眼看出瓶颈在哪里。

cargo install flamegraph
cargo flamegraph --bin my_program
# 在项目根目录生成 flamegraph.svg，浏览器打开

火焰图读法：X 轴是时间，Y 轴是调用栈深度，最宽的那些”山峰”就是你要打的地方。山越高、越宽，说明占用时间越多。

进阶用法：

# 设置采样频率（默认 99Hz，高频场景可以调到 1000Hz）
flamegraph -F 1000 -- /path/to/binary

# 禁用内联，让热点函数独立显示
cargo flamegraph --no-inline

# 直接对 benchmark 生成火焰图
cargo flamegraph --bench some_benchmark

生成的 SVG 可以直接丢进 CI——每次 commit 跑一次，对比火焰图变化，抓回归。

—

## 三套工具怎么选

| 场景 | 推荐工具 | 原因 |
|——|———|——|
| macOS 开发机 | samply | 一行安装，直接开 Firefox Profiler 界面，交互最顺 |
| Linux 服务器 | perf | 内核级硬件计数器，Cache miss/Branch miss 都能看 |
| CI 自动化 | flamegraph SVG | 输出文件化，可存档对比 |
| 内存泄漏 / 分配热点 | dhat | 跨平台，输出直接是 Web 页面 |
| 内存 timeline 趋势 | Valgrind massif | 全程记录，不过跑一次要 10-50x 时间 |

—

## 实操：从”猜”到”看见”

**场景：** JSON 解析器跑 10MB 文件要 2.5 秒。

第一步，跑 benchmark 确认问题：

cargo bench
# 输出：parsing 10MB JSON: 2.5s

第二步，生成火焰图：

cargo flamegraph --bin json_parser
# 打开 flamegraph.svg，看到 60% 的时间卡在 String::from 和 to_lowercase

第三步，定位根因：每个 token 调用 to_lowercase() 都在 new String，allocation 热点。

第四步，上 bumpalo 重用 buffer，复测：

cargo bench
# 输出：parsing 10MB JSON: 1.8s → 25% 提升

第五步，再打一次火焰图，确认热点已经转移。

—

## 下一步：马上可落地的清单

**今天就能做的：**

1. `cargo install dhat`——在任意 Rust 项目里加三行代码跑一次，看看内存到底被谁吃了
2. `cargo install samply`——对本地某个 binary 跑一次采样，打开 Firefox Profiler 看看火焰图长什么样
3. 对 benchmark 加 `–features dhat-heap`——长期跑的二进制，加这个 flag 跑一周，抓内存泄漏
4. CI 里加 `cargo flamegraph –bin xxx`——每次 MR 打一次，PR 描述里附火焰图 diff，用图片替代”我觉得性能变差了”

配 Rust 配了三年，你可能一直在靠猜优化。猜哪个函数慢，猜哪个循环吃内存，猜哪个路径是热点——今天这件事可以不用猜了。