Rust 基准测试
用基准而非一次计时做性能判断；criterion 等工具的角色与方法论要点。
#concept
#growing
#dev
#rust
[!info] related notes
Rust 基准测试
这个概念为什么出现
一次 Instant::now 测不准噪声。
基准测试重复运行、统计处理，才能比较优化是否真有效。
[!abstract] 一句话理解 基准在统计意义上测量热点；Rust 常用
criterion等工具（nightly 也有内置 bench 历史路径）；没有测量就没有优化。
最小可运行示例
场景：测量一次 u64 字符串解析
# 业务意图：为热点函数准备 bench 入口。
# 教学点：benches 目录与自定义 benchmark harness。
mkdir -p benches在已有 Cargo 项目的清单中追加配置（不要重复已有 dev-dependencies 表）。此示例固定 Criterion 0.5 系列以便复现，不表示它是最新版：
[dev-dependencies]
criterion = "0.5"
[[bench]]
name = "parse_bench"
harness = falsebenches/parse_bench.rs：
use criterion::{criterion_group, criterion_main, Criterion};
use std::hint::black_box;
fn parse_benchmark(c: &mut Criterion) {
c.bench_function("parse_u64", |b| {
b.iter(|| black_box(black_box("123456789").parse::<u64>().unwrap()))
});
}
criterion_group!(benches, parse_benchmark);
criterion_main!(benches);执行 cargo bench —bench parse_bench，应出现 parse_u64 的预热、采样和时间区间；cargo bench —bench parse_bench — —test 仅验证入口能运行，不给性能结论。单个输入只验证这一条路径，比较策略时还需代表性长度、无效输入和相同输出语义。
结合场景再看三个关注点
- 用 std::hint::black_box 降低输入常量折叠和结果删除风险；它是尽力而为的优化屏障，不是正确性或密码学保证
- 固定输入集
- 发布模式测量
核心概念与准确模型
- 预热、样本、置信
- 比较前后 commit
- 微基准 vs 端到端
- 性能回归 CI（谨慎抖动）
设计动机
- 用数据代替口号
- 与零成本抽象主张对齐验证
边界与误区
- 在 debug 构建上比性能
- 基准与真实负载脱节
- 过早微优化
[!warning] 常见误区：一次运行定胜负 必须重复与统计。
工程实践
- 先 profile 找热点
- 再写微基准验证
- 记录机器与版本
- 结合 方法论
本节总结
- 统计基准
- criterion 常用
- 测量驱动优化
自测题
- 为什么不要在 debug 比性能？
- black_box 目的？
参考答案
- 优化关闭，结论偏差。
- 降低常量折叠与无用结果删除导致虚假测量的风险；仍应检查基准是否测到了目标工作。
延伸阅读与资料来源
| 资料 | 类型 | 支撑内容 |
|---|---|---|
| Criterion.rs | 生态 | 基准框架 |
| Cargo bench | 官方 | 命令 |
Digital Biome