[!info] 关联笔记

• 所属 MOC：测试与质量 · 学习路线
• 前置概念：测试、Cargo
• 后续概念：性能方法论
• 容易混淆：功能测试

Rust 基准测试

这个概念为什么出现

一次 Instant::now 测不准噪声。
基准测试重复运行、统计处理，才能比较优化是否真有效。

[!abstract] 一句话理解 基准在统计意义上测量热点；Rust 常用 criterion 等工具（nightly 也有内置 bench 历史路径）；没有测量就没有优化。

最小可运行示例

场景：比较两种解析策略前先建基准目录

# 业务意图：为热点函数准备 bench 入口。
# 教学点：benches 目录；criterion 依赖（示意）。

mkdir -p benches

Cargo.toml 示意：

[dev-dependencies]
criterion = "0.5"

[[bench]]
name = "parse_bench"
harness = false

benches/parse_bench.rs 概念骨架：

// 使用 criterion 的黑盒防优化掉计算（细节见 criterion 文档）
fn main() {
    println!("see criterion docs for full template");
}

跑：cargo bench（需配置完整）。

结合场景再看三个关注点

1. 防编译器优化掉工作（black_box）
2. 固定输入集
3. 发布模式测量

核心概念与准确模型

• 预热、样本、置信
• 比较前后 commit
• 微基准 vs 端到端
• 性能回归 CI（谨慎抖动）

设计动机

• 用数据代替口号
• 与零成本抽象主张对齐验证

边界与误区

• 在 debug 构建上比性能
• 基准与真实负载脱节
• 过早微优化

[!warning] 常见误区：一次运行定胜负 必须重复与统计。

工程实践

1. 先 profile 找热点
2. 再写微基准验证
3. 记录机器与版本
4. 结合 方法论

本节总结

• 统计基准
• criterion 常用
• 测量驱动优化

自测题

1. 为什么不要在 debug 比性能？
2. black_box 目的？

参考答案

1. 优化关闭，结论偏差。
2. 防止编译器把计算优化掉导致虚假结果。

延伸阅读与资料来源

资料	类型	支撑内容
Criterion.rs	生态	基准框架
Cargo bench	官方	命令