如何使用libtest bench对Rust代码进行基准测试

Everett Pompeii

什么是基准测试？

基准测试是测试代码性能的实践，以查看它的速度（延迟）或工作量（吞吐量）。在软件开发中，这一步通常被忽视，但对于创建和维护快速且高性能的代码至关重要。基准测试为开发人员提供了必要的指标，以了解他们的代码在各种工作负载和条件下的表现。出于与编写单元测试和集成测试以防止功能回归相同的原因，你应该编写基准测试以防止性能回归。性能错误也是错误！

用 Rust 编写 FizzBuzz

为了编写基准测试，我们需要一些源代码来进行基准测试。首先，我们将编写一个非常简单的程序， FizzBuzz。

FizzBuzz的规则如下：

写一个程序，打印从 1 到 100 的整数（包含）：

对于三的倍数，打印 Fizz

对于五的倍数，打印 Buzz

对于既是三的倍数又是五的倍数的数，打印 FizzBuzz

对于所有其他数，打印这个数字

有许多种编写FizzBuzz的方法。所以我们会选择我最喜欢的一种：

fn main() {
    for i in 1..=100 {
        match (i % 3, i % 5) {
            (0, 0) => println!("FizzBuzz"),
            (0, _) => println!("Fizz"),
            (_, 0) => println!("Buzz"),
            (_, _) => println!("{i}"),
        }
    }
}

创建一个 main 函数
从 1 迭代到 100（含）。
对于每个数字，分别计算 3 和 5 的取余（除后余数）。
对两个余数进行模式匹配。如果余数为 0，那么这个数就是给定因素的倍数。
如果 3 和 5 的余数都为 0，则打印 FizzBuzz。
如果只有 3 的余数为 0，则打印 Fizz。
如果只有 5 的余数为 0，则打印 Buzz。
否则，就打印这个数字。

按步骤操作

为了与本教程进行同步学习，您需要安装 Rust。

🐰 这篇文章的源代码在 GitHub 上可以找到

安装好 Rust 后，您可以打开一个终端窗口，然后输入：cargo init game

然后导航至新创建的 game 目录。

game
├── Cargo.toml
└── src
    └── main.rs

你应该能看到一个名为 src 的目录，其中有一个名为 main.rs 的文件：

fn main() {
    println!("Hello, world!");
}

将其内容替换为上述的 FizzBuzz 实现。然后运行 cargo run。输出结果应该像这样：

$ cargo run
   Compiling playground v0.0.1 (/home/bencher)
    Finished dev [unoptimized + debuginfo] target(s) in 0.44s
     Running `target/debug/game`

1
2
Fizz
4
Buzz
Fizz
7
8
Fizz
Buzz
11
Fizz
13
14
FizzBuzz
...
97
98
Fizz
Buzz

🐰 砰！你正在破解编程面试！

应该生成了一个新的 Cargo.lock 文件：

game
├── Cargo.lock
├── Cargo.toml
└── src
    └── main.rs

在进一步探讨之前，有必要讨论微基准测试和宏基准测试之间的区别。

微基准测试 vs 宏基准测试

有两大类软件基准测试：微基准测试和宏基准测试。微基准测试的操作层次和单元测试类似。例如，为一个确定单个数字是 Fizz、 Buzz，还是 FizzBuzz 的函数设立的基准测试，就是一个微基准测试。宏基准测试的操作层次和集成测试类似。例如，为一函数设立的基准测试，该函数可以玩完整个 FizzBuzz 游戏，从 1 到 100，这就是一个宏基准测试。

通常，尽可能在最低的抽象级别进行测试是最好的。在基准测试的情况下，这使得它们更易于维护，并有助于减少测量中的噪声。然而，就像有一些端到端测试对于健全性检查整个系统根据预期组合在一起非常有用一样，拥有宏基准测试对于确保您的软件中的关键路径保持高性能也非常有用。

在 Rust 中进行基准测试

在 Rust 中进行基准测试的三个热门选项是： libtest bench, Criterion, 和 Iai。

libtest 是 Rust 内置的单元测试和基准测试框架。虽然它是 Rust 标准库的一部分，但 libtest bench 仍被认为是不稳定的，因此仅在 nightly 编译器版本中可用。要在稳定版 Rust 编译器上工作，则需要使用一个单独的基准测试工具。然而，这两者都没有得到积极的开发。

Rust 生态系统中最流行的基准测试工具是 Criterion。它可以在稳定版和 nightly Rust 编译器版本上工作，并且已经成为 Rust 社区内事实上的标准。相比 libtest bench，Criterion 还具有更多的功能。

Criterion 的一个实验性替代品是 Iai，同样出自 Criterion 的创建者。然而，它使用指令计数而不是墙钟时间：CPU 指令、L1 访问、L2 访问和 RAM 访问。这允许一次性基准测试，因为这些指标在不同运行之间应该几乎保持相同。

所有这三个都是由Bencher支持。那么为什么要选择libtest bench呢? 如果你试图限制项目的外部依赖，并且你的项目已经使用了夜间版工具链，那么这可能是个好主意。除此之外，根据你的使用场景，我会建议使用 Criterion 或者 Iai。

安装Rust `夜间版`

那么说了这么多，我们要用到libtest bench，所以让我们将Rust工具链设置为夜间版。在你的game项目的根目录中创建一个rust-toolchain.toml文件，与Cargo.toml同级。

[toolchain]
channel = "nightly"

你的目录结构现在应该看起来像这样：

game
├── Cargo.lock
├── Cargo.toml
├── rust-toolchain.toml
└── src
    └── main.rs

一旦完成，重新运行cargo run。新的夜间版工具链的安装应该会花费一点时间，然后再重新运行，然后给出和以前一样的输出。

重构 FizzBuzz

为了测试我们的FizzBuzz应用，我们需要从程序的main函数中分离出我们的逻辑。基准测试工具无法对main函数进行基准测试。

请更新您的代码以使它看起来像这样：

fn main() {
    for i in 1..=100 {
        play_game(i);
    }
}

pub fn play_game(n: u32) {
    println!("{}", fizz_buzz(n));
}

pub fn fizz_buzz(n: u32) -> String {
    match (n % 3, n % 5) {
        (0, 0) => "FizzBuzz".to_string(),
        (0, _) => "Fizz".to_string(),
        (_, 0) => "Buzz".to_string(),
        (_, _) => n.to_string(),
    }
}

我们现在已经把我们的代码分离成了三个不同的函数：

main：我们程序的主要入口点，它遍历1至100（包含）的数字，并对每一个数字调用play_game函数。
play_game：接取一个无符号整数n，调用fizz_buzz并使用那个数值，并打印结果。
fizz_buzz：接取一个无符号整数n，然后实际进行Fizz，Buzz，FizzBuzz，或数字逻辑，并以字符串形式返回结果。

对FizzBuzz进行基准测试

为了使用不稳定的libtest crate，我们需要启用我们代码的test特性并导入test crate。在main.rs的_顶部_添加以下内容：

#![feature(test)]
extern crate test;

现在我们准备添加我们的第一个基准测试！在main.rs的_底部_添加以下内容：

#[cfg(test)]
mod benchmarks {
    use test::Bencher;

    use super::play_game;

    #[bench]
    fn bench_play_game(b: &mut Bencher) {
        b.iter(|| {
            std::hint::black_box(for i in 1..=100 {
                play_game(i)
            });
        });
    }
}

创建一个名为benchmarks的模块，并设置编译器配置为测试模式。
引入Bencher基准测试运行器。（🐰 哇，酷名字！）
引入我们的play_game功能。
创建一个名为bench_play_game的基准，它接受一个指向Bencher的可变引用。
设置#[bench]属性以表明bench_play_game是一个基准。
使用Bencher实例 (b)多次运行我们的宏基准。
在一个”黑匣子”里运行我们的宏基准，以便编译器不优化我们的代码。
从1迭代到100（包含）。
对每个数字，调用play_game。

现在我们准备对我们的代码进行基准测试，运行cargo bench：

$ cargo bench
   Compiling playground v0.0.1 (/home/bencher)
    Finished bench [optimized] target(s) in 0.02s
     Running unittests src/main.rs (target/release/deps/game-68f58c96f4025bd4)

running 1 test
test benchmarks::bench_play_game ... bench:       4,879 ns/iter (+/- 170)

test result: ok. 0 passed; 0 failed; 0 ignored; 1 measured; 0 filtered out; finished in 0.68s

🐰 让我们加大胡萝卜的力量！我们已经拿到了我们的第一份基准测试度量数据！

终于，我们可以让自己疲惫的开发者大脑休息一下… 开玩笑的，我们的用户想要一个新特性！

用 Rust 编写 FizzBuzzFibonacci

我们的关键绩效指标（KPI）下降了，所以我们的产品经理（PM）希望我们添加新功能。经过多次头脑风暴和许多用户采访后，我们决定光有 FizzBuzz 已经不够了。现在的孩子们希望有一个新的游戏，FizzBuzzFibonacci。

FizzBuzzFibonacci的规则如下：

编写一个程序，打印从 1 到 100 的整数（包括）：

对于三的倍数，打印 Fizz

对于五的倍数，打印 Buzz

对于既是三的倍数又是五的倍数的，打印 FizzBuzz

对于是斐波那契数列的数字，只打印 Fibonacci

对于所有其他的，打印该数

斐波那契数列是一个每个数字是前两个数字之和的序列。例如，从 0 和 1开始，斐波那契数列的下一个数字将是 1。后面是：2, 3, 5, 8 等等。斐波那契数列的数字被称为斐波那契数。所以我们将不得不编写一个检测斐波那契数的函数。

有许多方法可以编写斐波那契数列，同样也有许多方法可以检测一个斐波那契数。所以我们将采用我的最爱：

fn is_fibonacci_number(n: u32) -> bool {
    for i in 0..=n {
        let (mut previous, mut current) = (0, 1);
        while current < i {
            let next = previous + current;
            previous = current;
            current = next;
        }
        if current == n {
            return true;
        }
    }
    false
}

创建一个名为 is_fibonacci_number 的函数，该函数接收一个无符号整数，并返回一个布尔值。
遍历从 0 到我们给定的数 n（包含 n）的所有数字。
用 0 和 1 分别作为前一个 和 当前 数字来初始化我们的斐波那契序列。
当当前数字小于当前迭代 i 时持续迭代。
添加前一个 和 当前 数字来获得 下一个 数字。
将 前一个 数字更新为 当前 数字。
将 当前 数字更新为 下一个 数字。
一旦 当前 大于或等于给定数字 n，我们将退出循环。
检查 当前 数字是否等于给定数字 n，如果是，则返回 true。
否则，返回 false。

现在我们需要更新我们的 fizz_buzz 功能：

pub fn fizz_buzz_fibonacci(n: u32) -> String {
    if is_fibonacci_number(n) {
        "Fibonacci".to_string()
    } else {
        match (n % 3, n % 5) {
            (0, 0) => "FizzBuzz".to_string(),
            (0, _) => "Fizz".to_string(),
            (_, 0) => "Buzz".to_string(),
            (_, _) => n.to_string(),
        }
    }
}

将 fizz_buzz 功能重命名为 fizz_buzz_fibonacci 以使其更具描述性。
调用我们的 is_fibonacci_number 辅助函数。
如果 is_fibonacci_number 的结果为 true，则返回 Fibonacci。
如果 is_fibonacci_number 的结果为 false，则执行相同的 Fizz、Buzz、FizzBuzz 或数字逻辑，并返回结果。

因为我们将 fizz_buzz 重命名为 fizz_buzz_fibonacci，我们也需要更新我们的 play_game 功能：

pub fn play_game(n: u32) {
    println!("{}", fizz_buzz_fibonacci(n));
}

我们的 main 和 bench_play_game 功能可以保持完全相同。

对FizzBuzzFibonacci进行基准测试

现在我们可以重新运行我们的基准：

$ cargo bench
   Compiling playground v0.0.1 (/home/bencher)
    Finished bench [optimized] target(s) in 0.00s
     Running unittests src/main.rs (target/release/deps/game-68f58c96f4025bd4)

running 1 test
test benchmarks::bench_play_game ... bench:      22,167 ns/iter (+/- 502)

test result: ok. 0 passed; 0 failed; 0 ignored; 1 measured; 0 filtered out; finished in 0.62s

回看我们的终端历史记录，我们可以用眼睛比较FizzBuzz和FizzBuzzFibonacci游戏的性能：4,879 ns对22,167 ns。你的数字可能会和我有一点点不同。不过，两款游戏的差距可能在5倍的范围内。这对我来说看起来不错！特别是对添加了像_Fibonacci_这样花哨 sounding 的功能到我们的游戏。孩子们会爱上它的！

在 Rust 中展开 FizzBuzzFibonacci

我们的游戏很受欢迎！孩子们确实喜欢玩 FizzBuzzFibonacci。为此，高层下达了他们想要续集的消息。但这是现代世界，我们需要的是年度循环收入（ARR），而不是一次性购买！我们游戏的新愿景是开放性的，不再固定在 1 和 100 之间（即使是包含在内的）。不，我们正在开拓新的疆域！

Open World FizzBuzzFibonacci的规则如下：

编写一个程序，它接受_任何_正整数并打印：

对于三的倍数，打印 Fizz

对于五的倍数，打印 Buzz

对于同时是三和五的倍数的，则打印 FizzBuzz

对于是斐波那契数列的数字，只打印 Fibonacci

对于其他所有数字，打印该数字

为了让我们的游戏适应任何数字，我们需要接受一个命令行参数。将 main 函数更新为如下形式：

fn main() {
    let args: Vec<String> = std::env::args().collect();
    let i = args
        .get(1)
        .map(|s| s.parse::<u32>())
        .unwrap_or(Ok(15))
        .unwrap_or(15);
    play_game(i);
}

收集所有从命令行传递给我们游戏的参数（args）。
获取传递给我们游戏的第一个参数，并将其解析为无符号整数 i。
如果解析失败或没有传入参数，就默认以 15 作为输入运行我们的游戏。
最后，用新解析的无符号整数 i 来玩我们的游戏。

现在我们可以用任何数字来玩我们的游戏了！使用 cargo run 后跟 -- 将参数传递给我们的游戏：

$ cargo run -- 9
   Compiling playground v0.0.1 (/home/bencher)
    Finished dev [unoptimized + debuginfo] target(s) in 0.44s
     Running `target/debug/game 9`
Fizz

$ cargo run -- 10
    Finished dev [unoptimized + debuginfo] target(s) in 0.03s
     Running `target/debug/game 10`
Buzz

$ cargo run -- 13
    Finished dev [unoptimized + debuginfo] target(s) in 0.04s
     Running `target/debug/game 13`
Fibonacci

如果我们省略或提供了无效的数字：

$ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.03s
     Running `target/debug/game`
FizzBuzz

$ cargo run -- bad
    Finished dev [unoptimized + debuginfo] target(s) in 0.05s
     Running `target/debug/game bad`
FizzBuzz

哇，这是一个仔细的测试过程！CI 通过了。我们的上司非常高兴。让我们发布吧！🚀

结束

🐰 … 也许这是你的职业生涯的结束？

开玩笑的！其实一切都在燃烧！🔥

起初，一切看似进行得顺利。但在周六早上02:07，我的寻呼机响了起来：

📟 你的游戏起火了！🔥

从床上匆忙爬起来后，我试图弄清楚发生了什么。我试图搜索日志，但这非常困难，因为一切都在不停地崩溃。最后，我发现了问题。孩子们！他们非常喜欢我们的游戏，以至于玩了高达一百万次！在一股灵感的闪现中，我添加了两个新的基准测试：

#[bench]
fn bench_play_game_100(b: &mut Bencher) {
    b.iter(|| std::hint::black_box(play_game(100)));
}

#[bench]
fn bench_play_game_1_000_000(b: &mut Bencher) {
    b.iter(|| std::hint::black_box(play_game(1_000_000)));
}

一个带有数字一百（100）的据此游戏的微观基准测试bench_play_game_100
一个带有数字一百万（1_000_000）的据此游戏的微观基准测试bench_play_game_1_000_000

当我运行的时候，我得到了这个：

$ cargo bench
   Compiling game v0.1.0 (/home/bencher)
    Finished bench [optimized] target(s) in 0.75s
     Running unittests src/main.rs (target/release/deps/game-6e1cb3355509b761)

running 3 tests
test benchmarks::bench_play_game           ... bench:      22,458 ns/iter (+/- 1,508)
test benchmarks::bench_play_game_100       ... bench:         439 ns/iter (+/- 21)

等一下… 等一下…

test benchmarks::bench_play_game_1_000_000 ... bench:   9,586,977 ns/iter (+/- 15,923)

什么！439 ns x 1,000 应该是 439,000 ns，不是 9,586,977 ns 🤯 即使我得到了正确的Fibonacci序列代码，我还是可能在某处有性能bug。

修复 Rust 中的 FizzBuzzFibonacci

让我们再次看一下 is_fibonacci_number 函数：

fn is_fibonacci_number(n: u32) -> bool {
    for i in 0..=n {
        let (mut previous, mut current) = (0, 1);
        while current < i {
            let next = previous + current;
            previous = current;
            current = next;
        }
        if current == n {
            return true;
        }
    }
    false
}

现在我在考虑性能，我意识到我有一个不必要的，额外的循环。我们可以完全摆脱 for i in 0..=n {} 循环，只需直接比较 current 值和给定的数字 (n) 🤦

fn is_fibonacci_number(n: u32) -> bool {
    let (mut previous, mut current) = (0, 1);
    while current < n {
        let next = previous + current;
        previous = current;
        current = next;
    }
    current == n
}

更新您的 is_fibonacci_number 函数。
用 0 和 1 初始化我们的斐波那契序列作为 previous 和 current 数字。
当 current 数字小于 给定数字 n 时迭代。
将 previous 和 current 数字相加以获得 next 数字。
把 previous 数字更新为 current 数字。
把 current 数字更新为 next 数字。
一旦 current 大于或等于给定的数字 n，我们将退出循环。
检查 current 数字是否等于给定的数字 n 并返回该结果。

现在让我们重新运行那些基准，看看我们做得怎么样：

$ cargo bench
   Compiling game v0.1.0 (/home/bencher)
    Finished bench [optimized] target(s) in 0.75s
     Running unittests src/main.rs (target/release/deps/game-6e1cb3355509b761)

running 3 tests
test benchmarks::bench_play_game           ... bench:       5,570 ns/iter (+/- 390)
test benchmarks::bench_play_game_100       ... bench:          46 ns/iter (+/- 3)
test benchmarks::bench_play_game_1_000_000 ... bench:          53 ns/iter (+/- 4)

test result: ok. 0 passed; 0 failed; 0 ignored; 3 measured; 0 filtered out; finished in 9.24s

哦，哇！我们的 bench_play_game 基准又回到了与原始的FizzBuzz差不多的地方。我希望我记得那个分数到底是多少。不过已经过去三周了。我的终端历史记录已经无法追溯那么长时间了。不过我想这个分数应该和它很接近！

bench_play_game_100 基准下降了将近10倍，从439 ns到46 ns。而bench_play_game_1_000_000基准下降了超过10,000倍！ 9,586,977 ns 降到 53 ns！

🐰 嗨，至少我们在这个性能bug进入生产环境之前发现了它…哦，对。忘记了…

在 CI 中捕获性能回归

由于我那个小小的性能错误，我们的游戏收到了大量的负面评论，这让高管们非常不满。他们告诉我不要让这种情况再次发生，而当我询问如何做到时，他们只是告诉我不要再犯。我该如何管理这个问题呢‽

幸运的是，我找到了这款叫做 Bencher 的超棒开源工具。它有一个非常慷慨的免费层，因此我可以在我的个人项目中使用 Bencher Cloud。而在工作中需要在我们的私有云内，我已经开始使用 Bencher Self-Hosted。

Bencher有一个内建的适配器，所以很容易集成到 CI 中。在遵循快速开始指南后，我能够运行我的基准测试并用 Bencher 追踪它们。

$ bencher run --project game "cargo bench"
    Finished bench [optimized] target(s) in 0.03s
     Running unittests src/main.rs (target/release/deps/game-6e1cb3355509b761)

running 3 tests
test benchmarks::bench_play_game           ... bench:       5,690 ns/iter (+/- 1,091)
test benchmarks::bench_play_game_100       ... bench:          48 ns/iter (+/- 7)
test benchmarks::bench_play_game_1_000_000 ... bench:          51 ns/iter (+/- 3)

test result: ok. 0 passed; 0 failed; 0 ignored; 3 measured; 0 filtered out; finished in 2.81s

Bencher New Report:
...
View results:
- benchmarks::bench_play_game (Latency): https://bencher.dev/console/projects/game/perf?measures=52507e04-ffd9-4021-b141-7d4b9f1e9194&branches=3a27b3ce-225c-4076-af7c-75adbc34ef9a&testbeds=bc05ed88-74c1-430d-b96a-5394fdd18bb0&benchmarks=077449e5-5b45-4c00-bdfb-3a277413180d&start_time=1697224006000&end_time=1699816009000&upper_boundary=true
- benchmarks::bench_play_game_100 (Latency): https://bencher.dev/console/projects/game/perf?measures=52507e04-ffd9-4021-b141-7d4b9f1e9194&branches=3a27b3ce-225c-4076-af7c-75adbc34ef9a&testbeds=bc05ed88-74c1-430d-b96a-5394fdd18bb0&benchmarks=96508869-4fa2-44ac-8e60-b635b83a17b7&start_time=1697224006000&end_time=1699816009000&upper_boundary=true
- benchmarks::bench_play_game_1_000_000 (Latency): https://bencher.dev/console/projects/game/perf?measures=52507e04-ffd9-4021-b141-7d4b9f1e9194&branches=3a27b3ce-225c-4076-af7c-75adbc34ef9a&testbeds=bc05ed88-74c1-430d-b96a-5394fdd18bb0&benchmarks=ff014217-4570-42ea-8813-6ed0284500a4&start_time=1697224006000&end_time=1699816009000&upper_boundary=true

使用这个由一个友善的兔子给我的巧妙的时间旅行设备，我能够回到过去，重演如果我们一直都在使用Bencher的情况下会发生什么。你可以看到我们首次推出存在问题的FizzBuzzFibonacci实现的位置。我马上在我的拉取请求评论中得到了CI的失败信息。就在那天，我修复了性能问题，摆脱了那不必要的额外循环。没有火灾。顾客都非常开心。

Bencher: 持续性能基准测试

Bencher是一套持续型的性能基准测试工具。你是否曾经因为性能回归影响到了你的用户？ Bencher可以防止这种情况的发生。 Bencher让你有能力在性能回归进入生产环境之前就进行检测和预防。

运行: 使用你喜爱的基准测试工具在本地或CI中执行你的基准测试。bencher CLI简单地包装了你现有的基准测验设备并存储其结果。
追踪: 追踪你的基准测试结果的趋势。根据源分支、测试床和度量，使用Bencher web控制台来监视、查询和绘制结果图表。
捕获: 在CI中捕获性能回归。Bencher使用最先进的、可定制的分析技术在它们进入生产环境之前就检测到性能回归。

基于防止功能回归的原因，在CI中运行单元测试，我们也应该使用Bencher在CI中运行基准测试以防止性能回归。性能问题就是错误！

开始在CI中捕捉性能回归 — 免费试用Bencher Cloud。

🤖 该文档由 OpenAI GPT-4 自动生成。它可能不准确并且可能包含错误。如果您发现任何错误，请在 GitHub 上提出问题.