rust

性能剖析与优化

Rust 性能剖析与优化实战：perf 与 cargo-flamegraph 定位热点、内存分配剖析（DHAT/heaptrack）、缓存友好与数据结构布局（SoA/AoS、SmallVec、repr）、零成本抽象的边界（泛型 vs dyn、内联）、LTO/PGO/target-cpu 编译优化选项与实测收益。

Leeting Yan 6 分钟阅读 2800 字

「Rust 很快」是编译期安全的副产品，不是免费的午餐。写出来的 Rust 完全可能比等价的 C 慢几倍——多余的 clone、Box<dyn Trait> 的动态分发、每帧一次堆分配，都是常见元凶。

优化必须建立在测量之上，否则就是猜。本文给出从采样剖析到编译选项的完整链路：先用 perf/flamegraph 找到真正热的那 5%，再讨论分配、缓存和抽象成本，最后是编译器的旋钮。系统级的零拷贝与 mmap 手法在 Rust 系统编程 里展开，这里聚焦「怎么定位与验证」。

测量优先：剖析工具

三种剖析视角

视角工具回答的问题
CPU 采样perf、cargo flamegraph、samply时间花在哪个函数
分配剖析dhat、heaptrack谁在分配、分配多少次
统计基准criterion这次改动快了多少

第一步永远是采样，它给出方向；分配剖析解释「为什么慢」；criterion 负责验证「改完真的快了」。

perf 与火焰图

基础采样

# 发布构建 + 调试符号（release 也带符号，便于火焰图可读）
[profile.release]
debug = 1          # 或 "line-tables-only"，体积增加很小

cargo build --release
perf record -g --call-graph dwarf ./target/release/server --bench-mode
perf report                    # 交互式查看
perf stat ./target/release/server    # 只看 IPC、cache-miss 等计数器

perf stat 的指标比耗时更有信息量：

1,234,567,890  instructions      # 指令数
  456,789,012  cycles            # 周期数
      2.70     insn per cycle    # IPC：< 1 说明大量停顿（内存/分支）
     12.34%    cache-misses      # 高则考虑数据结构布局

IPC 低而 cache-miss 高，问题在内存访问而非算法；IPC 正常但慢，说明在等 I/O 或锁。

cargo flamegraph

cargo install flamegraph
cargo flamegraph --bin myapp -- --workload big
# 生成 flamegraph.svg，宽度即时间占比

火焰图里看三件事：最宽的帧（时间大头）、最深的调用链（意外的递归或层层包装）、分散的浅帧（大量小函数调用，考虑内联）。若图里出现大量 memcpy、malloc、_int_malloc，问题在分配而非计算。

macOS 上用 samply 更方便（无需 perf 权限）：

cargo install samply
samply record ./target/release/myapp

生产环境剖析

线上不能用 perf 常驻，但可以低频采样并上传：

# 每 60 秒采 10 秒，控制开销在 1% 以内
perf record -F 99 -g -p $(pidof server) -- sleep 10

持续的、低开销的 CPU 剖析（continuous profiling）能把「偶发慢请求」也归因到函数级，思路与 持续性能剖析 一致。

分配与内存

定位分配热点

分配本身不慢，分配次数才是杀手。dhat 能精确统计每个调用点的分配次数与字节数：

// 在 main 或测试入口安装
#[cfg(feature = "profiling")]
fn main() {
    let _profiler = dhat::Profiler::new_heap();
    run();
}

[dev-dependencies]
dhat = "0.3"

跑完生成 dhat-heap.json，用在线 viewer 打开，按「总字节」和「分配次数」两个维度排序。经验值：热路径上每帧/每请求的分配次数应是个位数。

减少分配的常用手段

// 1. 预分配容量，避免 Vec 反复扩容（每次扩容都要拷贝）
let mut out = Vec::with_capacity(input.len());

// 2. 复用缓冲区：把 Vec 借出去再拿回来
fn encode_into(buf: &mut Vec<u8>, v: &Value) { buf.clear(); /* 复用已有容量 */ }

// 3. 小对象走栈：≤ 24 字节的集合用 SmallVec 免堆分配
use smallvec::SmallVec;
let mut ids: SmallVec<[u64; 8]> = SmallVec::new();   // ≤8 个元素全在栈上

// 4. 字符串拼接用 write! 到已有缓冲
use std::fmt::Write;
let mut s = String::with_capacity(64);
write!(s, "{}-{}", a, b).unwrap();

换分配器

默认的 glibc malloc 在多线程下表现一般，高并发服务换 mimalloc 或 jemalloc 常能直接拿到 10~30% 提升：

[dependencies]
mimalloc = { version = "0.1", default-features = false }

#[global_allocator]
static GLOBAL: mimalloc::MiMalloc = mimalloc::MiMalloc;

缓存友好与数据布局

现代 CPU 访问内存的延迟是 L1 的百倍级，布局往往比算法更影响实际性能。

AoS 与 SoA

// AoS（Array of Structs）：遍历时会把不需要的字段也拉进缓存
struct Particle { pos: [f32; 3], vel: [f32; 3], color: u32, mass: f32 }
let ps: Vec<Particle> = ...;

// SoA（Struct of Arrays）：只读需要的字段，缓存利用率高
struct Particles {
    pos: Vec<[f32; 3]>,
    vel: Vec<[f32; 3]>,
}

若热点循环只用到 pos，AoS 每读一个 pos 就浪费约 3/4 的缓存行带宽；SoA 把利用率拉满。反过来，若总是整体访问一个对象，AoS 更简单也更快。

缩小结构体

// ❌ 24 字节：两个枚举各占 8 字节（对齐）
enum State { Idle, Running }

// ✅ 用 u8 编码，配合 repr 控制布局
#[repr(u8)]
enum State { Idle = 0, Running = 1 }

// 用 NonZero 优化 Option 的内存占用
use std::num::NonZeroU64;
struct Handle(Option<NonZeroU64>);   // 与 u64 同为 8 字节，None 用 0 表示

Option<NonZeroU64>、Option<&T>、Option<Box<T>> 都是零开销的：编译器用非法值表示 None。而 Option<u64> 会额外占 8 字节——热结构体里改用 NonZeroU64 常能省下一半内存，直接转化为缓存命中率。

排序与局部性

链表遍历在现代 CPU 上极慢（每次跳转都可能 cache miss）。能用 Vec 就别用 LinkedList；需要「链表式」结构时，用索引向量代替指针：

// 用 u32 索引代替 Box<Node>，节点连续存放，遍历友好
struct Graph { nodes: Vec<Node>, edges: Vec<[u32; 2]> }

零成本抽象的边界

Rust 的「零成本抽象」指编译期能消解的抽象不产生运行时开销，但有些抽象消解不掉。

泛型 vs dyn

// 泛型：单态化，内联后无间接调用，但代码体积膨胀
fn sum<T: Iterator<Item = u64>>(it: T) -> u64 { it.sum() }

// dyn：动态分发，每次调用一次 vtable 查表，无法内联
fn sum_dyn(it: Box<dyn Iterator<Item = u64>>) -> u64 { it.sum() }

热路径优先泛型；需要异质集合或减少编译时间/体积时用 dyn。判断标准是调用频次：每次请求一次 dyn 调用无所谓，每元素一次就要评估。

迭代器不总是零成本

// 链式迭代器通常会被完全内联成单个循环
let total: u64 = data.iter().filter(|x| **x > 10).map(|x| x * 2).sum();

// 但闭包捕获、Box<dyn Iterator>、collect 到中间 Vec 会破坏内联
let mid: Vec<_> = data.iter().filter(|x| **x > 10).collect();   // 多余分配
let total: u64 = mid.iter().map(|x| x * 2).sum();

用 cargo asm 或 godbolt 验证关键循环是否被内联成期望的形态：

cargo install cargo-asm
cargo asm --release my_crate::hot_loop

#[inline] 的正确用法

跨 crate 的小函数默认不会被内联，这是最常见的隐性开销：

#[inline]                    // 跨 crate 的短函数
pub fn len(&self) -> usize { self.data.len() }

#[inline(always)]            // 极热、确定要内联（慎用，会撑大代码）
fn fast_path(x: u32) -> u32 { x & 0xff }

泛型函数天然可内联，#[inline] 主要解决「非泛型的跨 crate 小函数」。

编译优化选项

[profile.release]
opt-level = 3            # 默认即 3；体积敏感用 "s"/"z"
lto = "fat"              # 跨 crate 全局优化，收益 5~15%，编译显著变慢
codegen-units = 1        # 单编译单元，优化更彻底（也是 lto=fat 的前提）
panic = "abort"          # 去掉 unwind 表，减小体积、略快
strip = "symbols"        # 生产产物去符号
debug = 1                # 保留行号，便于线上剖析

# 本机指令集：只在自建构建机/容器上启用，分发二进制会 SIGILL
[target.x86_64-unknown-linux-gnu]
rustflags = ["-C", "target-cpu=native"]
选项典型收益代价
lto = "fat"5~15%编译时间翻倍
codegen-units = 13~10%增量编译失效
target-cpu=native5~20%（含 SIMD）二进制不可移植
panic = "abort"体积 -10%，略快无法 catch_unwind
PGO10~20%需要训练运行与两遍构建

PGO：用真实负载指导优化

PGO（Profile-Guided Optimization）用真实运行数据决定分支布局与内联：

# 1. 插桩构建
RUSTFLAGS="-Cprofile-generate=/tmp/pgo-data" cargo build --release
# 2. 跑真实负载
./target/release/server --replay prod-trace.log
# 3. 合并剖析数据并重编译
llvm-profdata merge -o /tmp/pgo-data/merged.profdata /tmp/pgo-data
RUSTFLAGS="-Cprofile-use=/tmp/pgo-data/merged.profdata -Cllvm-args=-pgo-warn-missing-function" \
  cargo build --release

PGO 的收益高度依赖训练负载是否贴近线上。收益大但流程重，适合长期稳定的服务，一次性工具不必上。CI 中固定 target-cpu 与 lto 配置的一致性，可参考 Rust 工具链精讲 里的构建矩阵。

优化检查清单

现象首选手段
火焰图里 malloc/memcpy 宽预分配、复用缓冲、SmallVec、换分配器
IPC < 1 且 cache-miss 高SoA 布局、缩小结构体、NonZero
热函数未被内联加 #[inline]、减少 dyn
单线程快、多线程不扩展查伪共享（CachePadded）、锁竞争
序列化占大头to_writer、换 bincode、避免 Value 中转
改了但没变快回到 criterion 复测，确认不是噪声

优化的顺序永远是：测量 → 假设 → 改一处 → 复测。一次改多个地方，就再也说不清哪一处起了作用。游戏服务这类高帧率场景的实战案例可参考 Rust 游戏服务器性能优化 。

继续阅读

探索更多技术文章

浏览归档，发现更多关于系统设计、工具链和工程实践的内容。

全部文章 返回首页

「rust」更多文章

  1. 测试与基准：criterion 与 proptest
  2. Serde 与序列化生态
  3. 并发原语与无锁编程