如何标准Rust代码与Criterion

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支持的。那么为什么要选择Criterion呢？ Criterion是Rust社区的事实标准基准测试工具。我推荐使用Criterion来测试你的代码的延迟。也就是说，Criterion非常适合测量时钟时间。

重构 FizzBuzz

为了测试我们的 FizzBuzz 应用，我们需要将逻辑从程序的 main 函数中解耦出来。基准测试工具无法对 main 函数进行基准测试。为了做到这一点，我们需要做一些改动。

在 src 下，创建一个新的名为 lib.rs 的文件：

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

将以下代码添加到 lib.rs：

pub fn play_game(n: u32, print: bool) {
    let result = fizz_buzz(n);
    if print {
        println!("{result}");
    }
}

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(),
    }
}

play_game：接受一个无符号整数 n，用该数字调用 fizz_buzz，如果 print 为 true，则打印结果。
fizz_buzz：接受一个无符号整数 n，执行实际的 Fizz、Buzz、FizzBuzz 或数字逻辑，然后将结果作为字符串返回。

然后更新 main.rs，使其看起来像这样：

use game::play_game;

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

game::play_game：从我们刚刚用 lib.rs 创建的 game 包中导入 play_game。
main：我们程序的主入口点，遍历从 1 到 100 的数字，对每个数字调用 play_game，并将 print 设为 true。

对FizzBuzz的基准测试

为了对我们的代码进行基准测试，我们需要创建一个benches目录，并添加一个文件来包含我们的基准测试，play_game.rs：

game
├── Cargo.lock
├── Cargo.toml
└── benches
    └── play_game.rs
└── src
    └── lib.rs
    └── main.rs

在play_game.rs中增加下列代码：

use criterion::{criterion_group, criterion_main, Criterion};

use game::play_game;

fn bench_play_game(c: &mut Criterion) {
    c.bench_function("bench_play_game", |b| {
        b.iter(|| {
            std::hint::black_box(for i in 1..=100 {
                play_game(i, false)
            });
        });
    });
}

criterion_group!(
    benches,
    bench_play_game,
);
criterion_main!(benches);

导入Criterion基准测试运行器。
从我们的game包中导入play_game函数。
创建一个名为bench_play_game的函数，它接受一个对Criterion的可变引用。
使用Criterion实例（c）来创建一个名为bench_play_game的基准测试。
然后使用基准测试运行器（b）来多次运行我们的宏基准测试。
在一个”黑箱”中运行我们的宏基准测试，这样编译器就不会优化我们的代码。
从1到100包括，进行迭代。
对于每一个数字，调用play_game，设置print为false。

现在我们需要配置game包来运行我们的基准测试。

在你的Cargo.toml文件的底部添加以下内容：

[dev-dependencies]
criterion = "0.5"

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

criterion：将criterion添加为开发依赖，因为我们只在性能测试中使用它。
bench：注册play_game作为一个基准测试，并设置harness为false，因为我们将使用Criterion作为我们的基准测试工具。

现在我们已经准备好进行基准测试了，运行cargo bench：

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

running 0 tests

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

     Running unittests src/main.rs (target/release/deps/game-043972c4132076a9)

running 0 tests

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

     Running benches/play_game.rs (target/release/deps/play_game-e0857103eb02eb56)
bench_play_game         time:   [3.0020 µs 3.0781 µs 3.1730 µs]
Found 12 outliers among 100 measurements (12.00%)
  2 (2.00%) high mild
  10 (10.00%) high severe

🐰 让我们调高节拍！我们已经得到了第一个基准测试指标！

最后，我们可以让我们疲倦的开发者头脑得到休息… 开玩笑，我们的用户想要一个新功能！

用 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, print: bool) {
    let result = fizz_buzz_fibonacci(n);
    if print {
        println!("{result}");
    }
}

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

对FizzBuzzFibonacci的基准测试

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

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

running 0 tests

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

     Running unittests src/main.rs (target/release/deps/game-043972c4132076a9)

running 0 tests

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

     Running benches/play_game.rs (target/release/deps/play_game-e0857103eb02eb56)
bench_play_game         time:   [20.067 µs 20.107 µs 20.149 µs]
                        change: [+557.22% +568.69% +577.93%] (p = 0.00 < 0.05)
                        Performance has regressed.
Found 6 outliers among 100 measurements (6.00%)
  4 (4.00%) high mild
  2 (2.00%) high severe

哦哦！Criterion向我们显示了FizzBuzz和FizzBuzzFibonacci游戏之间性能差距为+568.69%。你的数字会比我的稍微有些不同。然而，两者之间的差距可能在5x的范围内。这对我来说看起来是比较好的结果！特别是考虑到我们将像_Fibonacci_这样的花哨功能添加到我们的游戏中。孩子们会喜欢的！

在 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, true);
}

收集所有从命令行传递给我们游戏的参数（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，我的寻呼机响了起来：

📟 你的游戏起火了！🔥

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

fn bench_play_game_100(c: &mut Criterion) {
    c.bench_function("bench_play_game_100", |b| {
        b.iter(|| std::hint::black_box(play_game(100, false)));
    });
}

fn bench_play_game_1_000_000(c: &mut Criterion) {
    c.bench_function("bench_play_game_1_000_000", |b| {
        b.iter(|| std::hint::black_box(play_game(1_000_000, false)));
    });
}

一个用于玩游戏并输入数字一百（100）的微基准测试bench_play_game_100。
一个用于玩游戏并输入数字一百万（1_000_000）的微基准测试bench_play_game_1_000_000。

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

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

running 0 tests

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

     Running unittests src/main.rs (target/release/deps/game-043972c4132076a9)

running 0 tests

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

     Running benches/play_game.rs (target/release/deps/play_game-e0857103eb02eb56)
bench_play_game         time:   [20.024 µs 20.058 µs 20.096 µs]
                        change: [-0.0801% +0.1431% +0.3734%] (p = 0.21 > 0.05)
                        No change in performance detected.
Found 17 outliers among 100 measurements (17.00%)
  9 (9.00%) high mild
  8 (8.00%) high severe

bench_play_game_100     time:   [403.00 ns 403.57 ns 404.27 ns]
Found 13 outliers among 100 measurements (13.00%)
  6 (6.00%) high mild
  7 (7.00%) high severe

等待一下… 等待一下…

bench_play_game_1_000_000
                        time:   [9.5865 ms 9.5968 ms 9.6087 ms]
Found 16 outliers among 100 measurements (16.00%)
  8 (8.00%) high mild
  8 (8.00%) high severe

什么！403.57 ns x 1,000 应该是 403,570 ns 而不是 9,596,800 ns (9.5968 ms x 1_000_000 ns/1 ms) 🤯 尽管我的斐波那契数列代码功能上是正确的，我必须在某个地方有一个性能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 playground v0.0.1 (/home/bencher)
    Finished bench [optimized] target(s) in 4.79s
     Running unittests src/main.rs (target/release/deps/game-68f58c96f4025bd4)

running 0 tests

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

     Running unittests src/main.rs (target/release/deps/game-043972c4132076a9)

running 0 tests

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

     Running benches/play_game.rs (target/release/deps/play_game-e0857103eb02eb56)
bench_play_game         time:   [3.1201 µs 3.1772 µs 3.2536 µs]
                        change: [-84.469% -84.286% -84.016%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 5 outliers among 100 measurements (5.00%)
  1 (1.00%) high mild
  4 (4.00%) high severe

bench_play_game_100     time:   [24.460 ns 24.555 ns 24.650 ns]
                        change: [-93.976% -93.950% -93.927%] (p = 0.00 < 0.05)
                        Performance has improved.

bench_play_game_1_000_000
                        time:   [30.260 ns 30.403 ns 30.564 ns]
                        change: [-100.000% -100.000% -100.000%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 4 outliers among 100 measurements (4.00%)
  1 (1.00%) high mild
  3 (3.00%) high severe

哦哇！我们的bench_play_game基准测试回落到原来FizzBuzz测试的附近位置。我希望我能记住那个得分是多少。但是已经过了三个星期了。我的终端历史记录没有回溯这么远。而Criterion只会和最近的结果进行比较。但我认为这是很接近的！

bench_play_game_100基准测试的结果下降了近10倍，-93.950%。和bench_play_game_1_000_000基准测试的结果下降了超过10,000倍！从9,596,800 ns降到30.403 ns！我们甚至让Criterion的改变计数器达到了最大值，它只会达到-100.000%！

🐰 嘿，至少我们在性能bug赶到生产环境之前抓住了它… 哦，对了。算了…

在 CI 中捕获性能回归

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

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

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

$ bencher run --project game "cargo bench"
    Finished bench [optimized] target(s) in 0.07s
     Running unittests src/lib.rs (target/release/deps/game-13f4bad779fbfde4)

running 0 tests

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

     Running unittests src/main.rs (target/release/deps/game-043972c4132076a9)

running 0 tests

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

     Running benches/play_game.rs (target/release/deps/play_game-e0857103eb02eb56)
Gnuplot not found, using plotters backend
bench_play_game         time:   [3.0713 µs 3.0902 µs 3.1132 µs]
Found 16 outliers among 100 measurements (16.00%)
  3 (3.00%) high mild
  13 (13.00%) high severe

bench_play_game_100     time:   [23.938 ns 23.970 ns 24.009 ns]
Found 15 outliers among 100 measurements (15.00%)
  5 (5.00%) high mild
  10 (10.00%) high severe

bench_play_game_1_000_000
                        time:   [30.004 ns 30.127 ns 30.279 ns]
Found 5 outliers among 100 measurements (5.00%)
  1 (1.00%) high mild
  4 (4.00%) high severe

Bencher New Report:
...
View results:
- 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
- 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
- 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 上提出问题.