How to benchmark Rust code with Iai

What is Benchmarking?

Benchmarking is the practice of testing the performance of your code to see how fast (latency) or how much (throughput) work it can do. This often overlooked step in software development is crucial for creating and maintaining fast and performant code. Benchmarking provides the necessary metrics for developers to understand how well their code performs under various workloads and conditions. For the same reasons that you write unit and integration tests to prevent feature regressions, you should write benchmarks to prevent performance regressions. Performance bugs are bugs!

Write FizzBuzz in Rust

In order to write benchmarks, we need some source code to benchmark. To start off we are going to write a very simple program, FizzBuzz.

The rules for FizzBuzz are as follows:

Write a program that prints the integers from 1 to 100 (inclusive):

• For multiples of three, print Fizz
• For multiples of five, print Buzz
• For multiples of both three and five, print FizzBuzz
• For all others, print the number

There are many ways to write FizzBuzz. So we’ll go with the my favorite:

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

• Create a main function
• Iterate from 1 to 100 inclusively.
• For each number, calculate the modulus (remainder after division) for both 3 and 5.
• Pattern match on the two remainders. If the remainder is 0, then the number is a multiple of the given factor.
• If the remainder is 0 for both 3 and 5 then print FizzBuzz.
• If the remainder is 0 for only 3 then print Fizz.
• If the remainder is 0 for only 5 then print Buzz.
• Otherwise, just print the number.

Follow Step-by-Step

In order to follow along with this set-by-step tutorial, you will need to install Rust.

🐰 The source code for this post is available on GitHub

With Rust installed, you can then open a terminal window and enter: cargo init game

Then navigate into the newly created game directory.

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

You should see a directory called src with file named main.rs:

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

Replace its contents with the above FizzBuzz implementation. Then run cargo run. The output should look like:

$ 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

🐰 Boom! You’re cracking the coding interview!

A new Cargo.lock file should have been generated:

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

Before going any further, it is important to discuss the differences between micro-benchmarking and macro-benchmarking.

Micro-Benchmarking vs Macro-Benchmarking

There are two major categories of software benchmarks: micro-benchmarks and macro-benchmarks. Micro-benchmarks operate at a level similar to unit tests. For example, a benchmark for a function that determines Fizz, Buzz, or FizzBuzz for a single number would be a micro-benchmark. Macro-benchmarks operate at a level similar to integration tests. For example, a benchmark for a function that plays the entire game of FizzBuzz, from 1 to 100, would be a macro-benchmark.

Generally, it is best to test at the lowest level of abstraction possible. In the case benchmarks, this makes them both easier to maintain, and it helps to reduce the amount of noise in the measurements. However, just as having some end-to-end tests can be very useful for sanity checking the entire system comes together as expected, having macro-benchmarks can be very useful for making sure that the critical paths through your software remain performant.

Benchmarking in Rust

The three popular options for benchmarking in Rust are: libtest bench, Criterion, and Iai.

libtest is Rust’s built-in unit testing and benchmarking framework. Though part of the Rust standard library, libtest bench is still considered unstable, so it is only available on nightly compiler releases. To work on the stable Rust compiler, a separate benchmarking harness needs to be used. Neither is being actively developed, though.

The most popular benchmarking harness within the Rust ecosystem is Criterion. It works on both stable and nightly Rust compiler releases, and it has become the de facto standard within the Rust community. Criterion is also much more feature-rich compared to libtest bench.

An experimental alternative to Criterion is Iai, from the same creator as Criterion. However, it uses instruction counts instead of wall clock time: CPU instructions, L1 accesses, L2 access and RAM accesses. This allows for single-shot benchmarking since these metrics should stay nearly identical between runs.

All three are support by Bencher. So why choose Iai? Iai uses instruction counts instead of wall clock time. This makes it ideal for continuous benchmarking, that is benchmarking in CI. I would suggest using Iai for continuous benchmarking, especially if you are using shared runners. It is important to understand that Iai only measures a proxy for what you really care about. Does going from 1,000 instructions to 2,000 instructions double the latency of your application? Maybe or maybe not. For this reason, it can be useful to also run wall clock time based benchmarks in parallel with instruction count based benchmarks.

🐰 Iai hasn’t been update in over 3 years. So you might consider using Iai-Callgrind instead.

Install Valgrind

Iai uses a tool called Valgrind to collect instruction counts. Valgrind supports Linux, Solaris, FreeBSD, and MacOS. However, the MacOS support is limited to x86_64 processors as arm64 (M1, M2, etc) processors are not yet supported.

On Debian run: sudo apt-get install valgrind

On MacOS (x86_64/Intel chip only): brew install valgrind

Refactor FizzBuzz

In order to test our FizzBuzz application, we need to decouple our logic from our program’s main function. Benchmark harnesses can’t benchmark the main function. In order to do this, we need to make few changes.

Under src, create a new file named lib.rs:

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

Add the following code to 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: Takes in an unsigned integer n, calls fizz_buzz with that number, and if print is true prints the result.
• fizz_buzz: Takes in an unsigned integer n and performs the actual Fizz, Buzz, FizzBuzz, or number logic returning the result as a string.

Then update main.rs to look like this:

use game::play_game;

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

• game::play_game: Import play_game from the game crate we just created with lib.rs.
• main: The main entrypoint into our program that iterates through the numbers 1 to 100 inclusive and calls play_game for each number, with print set to true.

Benchmarking FizzBuzz

In order to benchmark our code, we need to create a benches directory and add file to contain our benchmarks, play_game.rs:

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

Inside of play_game.rs add the following code:

use game::play_game;

fn bench_play_game() {
    iai::black_box(for i in 1..=100 {
        play_game(i, false)
    });
}

iai::main!(bench_play_game);

• Import the play_game function from our game crate.
• Create a function named bench_play_game.
• Run our macro-benchmark inside of a “black box” so the compiler doesn’t optimize our code.
• Iterate from 1 to 100 inclusively.
• For each number, call play_game, with print set to false.

Now we need to configure the game crate to run our benchmarks.

Add the following to the bottom of your Cargo.toml file:

[dev-dependencies]
iai = "0.1"

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

• iai: Add iai as a development dependency, since we are only using it for performance testing.
• bench: Register play_game as a benchmark and set harness to false, since we will be using Iai as our benchmarking harness.

Now we’re ready to benchmark our code, run cargo bench:

$ cargo bench
   Compiling iai v0.1.1
   Compiling game v0.1.0 (/home/bencher)
    Finished bench [optimized] target(s) in 2.55s
     Running unittests src/lib.rs (target/release/deps/game-9b1b504669ca4b29)

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-8d61ca5a97299729)

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-6896309faf45cd96)
bench_play_game
  Instructions:               34370
  L1 Accesses:                50373
  L2 Accesses:                    9
  RAM Accesses:                  35
  Estimated Cycles:           51643

🐰 Lettuce turnip the beet! We’ve got our first benchmark metrics!

Finally, we can rest our weary developer heads… Just kidding, our users want a new feature!

Write FizzBuzzFibonacci in Rust

Our Key Performance Indicators (KPIs) are down, so our Product Manager (PM) wants us to add a new feature. After much brainstorming and many user interviews, it is decided that good ole FizzBuzz isn’t enough. Kids these days want a new game, FizzBuzzFibonacci.

The rules for FizzBuzzFibonacci are as follows:

Write a program that prints the integers from 1 to 100 (inclusive):

• For multiples of three, print Fizz
• For multiples of five, print Buzz
• For multiples of both three and five, print FizzBuzz
• For numbers that are part of the Fibonacci sequence, only print Fibonacci
• For all others, print the number

The Fibonacci sequence is a sequence in which each number is the sum of the two preceding numbers. For example, starting at 0 and 1 the next number in the Fibonacci sequence would be 1. Followed by: 2, 3, 5, 8 and so on. Numbers that are part of the Fibonacci sequence are known as Fibonacci numbers. So we’re going to have to write a function that detects Fibonacci numbers.

There are many ways to write the Fibonacci sequence and likewise many ways to detect a Fibonacci number. So we’ll go with the my favorite:

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
}

• Create a function named is_fibonacci_number that takes in an unsigned integer and returns a boolean.
• Iterate for all number from 0 to our given number n inclusive.
• Initialize our Fibonacci sequence starting with 0 and 1 as the previous and current numbers respectively.
• Iterate while the current number is less than the current iteration i.
• Add the previous and current number to get the next number.
• Update the previous number to the current number.
• Update the current number to the next number.
• Once current is greater than or equal to the given number n, we will exit the loop.
• Check to see is the current number is equal to the given number n and if so return true.
• Otherwise, return false.

Now we will need to update our fizz_buzz function:

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

• Rename the fizz_buzz function to fizz_buzz_fibonacci to make it more descriptive.
• Call our is_fibonacci_number helper function.
• If the result from is_fibonacci_number is true then return Fibonacci.
• If the result from is_fibonacci_number is false then perform the same Fizz, Buzz, FizzBuzz, or number logic returning the result.

Because we renamed fizz_buzz to fizz_buzz_fibonacci we also need to update our play_game function:

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

Both our main and bench_play_game functions can stay exactly the same.

Benchmarking FizzBuzzFibonacci

Now we can rerun our benchmark:

$ cargo bench
   Compiling game v0.1.0 (/home/bencher)
    Finished bench [optimized] target(s) in 2.20s
     Running unittests src/lib.rs (target/release/deps/game-9b1b504669ca4b29)

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-8d61ca5a97299729)

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-6896309faf45cd96)
bench_play_game
  Instructions:              304598 (+786.2322%)
  L1 Accesses:               320024 (+535.3086%)
  L2 Accesses:                    8 (-11.11111%)
  RAM Accesses:                  42 (+20.00000%)
  Estimated Cycles:          321534 (+522.6091%)

Oh, neat! Iai tells us the difference between the estimated cycles of our FizzBuzz and FizzBuzzFibonacci games is +522.6091%. Your numbers will be a little different than mine. However, the difference between the two games is likely in the 5x range. That seems good to me! Especially for adding a feature as fancy sounding as Fibonacci to our game. The kids will love it!

Expand FizzBuzzFibonacci in Rust

Our game is a hit! The kids do indeed love playing FizzBuzzFibonacci. So much so that word has come down from the execs that they want a sequel. But this is the modern world, we need Annual Recurring Revenue (ARR) not one time purchases! The new vision for our game is that it is open ended, no more living between the bound of 1 and 100 (even if it is inclusive). No, we’re on to new frontiers!

The rules for Open World FizzBuzzFibonacci are as follows:

Write a program that takes in any positive integer and prints:

• For multiples of three, print Fizz
• For multiples of five, print Buzz
• For multiples of both three and five, print FizzBuzz
• For numbers that are part of the Fibonacci sequence, only print Fibonacci
• For all others, print the number

In order to have our game work for any number, we will need to accept a command line argument. Update the main function to look like this:

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);
}

• Collect all of the arguments (args) passed to our game from the command line.
• Get the first argument passed to our game and parse it as an unsigned integer i.
• If parsing fails or no argument is passed in, default to playing our game with 15 as the input.
• Finally, play our game with the newly parsed unsigned integer i.

Now we can play our game with any number! Use cargo run followed by -- to pass arguments to our game:

$ 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

And if we omit or provide an invalid number:

$ 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

Wow, that was some thorough testing! CI passes. Our bosses are thrilled. Let’s ship it! 🚀

The End

🐰 … the end of your career maybe?

Just kidding! Everything is on fire! 🔥

Well, at first everything seemed to be going fine. And then at 02:07 AM on Saturday my pager went off:

📟 Your game is on fire! 🔥

After scrambling out of bed, I tried to figure out what was going on. I tried to search through the logs, but that was hard because everything kept crashing. Finally, I found the issue. The kids! They loved our game so much, they were playing it all the way up to a million! In a flash of brilliance, I added two new benchmarks:

fn bench_play_game_100() {
    iai::black_box(play_game(100, false));
}

fn bench_play_game_1_000_000() {
    iai::black_box(play_game(1_000_000, false));
}

• A micro-benchmark bench_play_game_100 for playing the game with the number one hundred (100)
• A micro-benchmark bench_play_game_1_000_000 for playing the game with the number one million (1_000_000)

When I ran it, I got this:

$ cargo bench
   Compiling game v0.1.0 (/home/bencher)
    Finished bench [optimized] target(s) in 1.92s
     Running unittests src/lib.rs (target/release/deps/game-9b1b504669ca4b29)

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-8d61ca5a97299729)

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-6896309faf45cd96)
bench_play_game
  Instructions:              304598 (No change)
  L1 Accesses:               320025 (+0.000312%)
  L2 Accesses:                    7 (-12.50000%)
  RAM Accesses:                  42 (No change)
  Estimated Cycles:          321530 (-0.001244%)

bench_play_game_100
  Instructions:                6194
  L1 Accesses:                 6290
  L2 Accesses:                    2
  RAM Accesses:                  11
  Estimated Cycles:            6685

Wait for it… wait for it…

bench_play_game_1_000_000
  Instructions:           155108715
  L1 Accesses:            155108811
  L2 Accesses:                    2
  RAM Accesses:                  11
  Estimated Cycles:       155109206

What! 6,685 estimated cycles x 1,000 should be 6,685,000 estimated cycles not 155,109,206 estimated cycles 🤯 Even though I got my Fibonacci sequence code functionally correct, I must have a performance bug in there somewhere.

Fix FizzBuzzFibonacci in Rust

Let’s take another look at that is_fibonacci_number function:

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
}

Now that I’m thinking about performance, I do realize that I have an unnecessary, extra loop. We can completely get rid of the for i in 0..=n {} loop and just compare the current value to the given number (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
}

• Update your is_fibonacci_number function.
• Initialize our Fibonacci sequence starting with 0 and 1 as the previous and current numbers respectively.
• Iterate while the current number is less than the given number n.
• Add the previous and current number to get the next number.
• Update the previous number to the current number.
• Update the current number to the next number.
• Once current is greater than or equal to the given number n, we will exit the loop.
• Check to see if the current number is equal to the given number n and return that result.

Now lets rerun those benchmarks and see how we did:

$ cargo bench
   Compiling game v0.1.0 (/home/bencher)
    Finished bench [optimized] target(s) in 4.22s
     Running unittests src/lib.rs (target/release/deps/game-9b1b504669ca4b29)

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-8d61ca5a97299729)

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-6896309faf45cd96)
bench_play_game
  Instructions:               38313 (-87.42178%)
  L1 Accesses:                53739 (-83.20787%)
  L2 Accesses:                    7 (No change)
  RAM Accesses:                  43 (+2.380952%)
  Estimated Cycles:           55279 (-82.80751%)

bench_play_game_100
  Instructions:                 295 (-95.23733%)
  L1 Accesses:                  389 (-93.81558%)
  L2 Accesses:                    2 (No change)
  RAM Accesses:                  13 (+18.18182%)
  Estimated Cycles:             854 (-87.22513%)

bench_play_game_1_000_000
  Instructions:                 391 (-99.99975%)
  L1 Accesses:                  485 (-99.99969%)
  L2 Accesses:                    2 (No change)
  RAM Accesses:                  13 (+18.18182%)
  Estimated Cycles:             950 (-99.99939%)

Oh, wow! Our bench_play_game benchmark is back down to around where it was for the original FizzBuzz. I wish I could remember exactly what that score was. It’s been three weeks though. My terminal history doesn’t go back that far. And Iai only compares against the most recent result. But I think it’s close!

The bench_play_game_100 benchmark is down nearly 10x, -87.22513%. And the bench_play_game_1_000_000 benchmark is down more than 10,000x! 155,109,206 estimated cycles to 950 estimated estimated cycles! That’s -99.99939%!

🐰 Hey, at least we caught this performance bug before it made it to production… oh, right. Nevermind…

Catch Performance Regressions in CI

The execs weren’t happy about the deluge of negative reviews our game received due to my little performance bug. They told me not to let it happen again, and when I asked how, they just told me not to do it again. How am I supposed to manage that‽

Luckily, I’ve found this awesome open source tool called Bencher. There’s a super generous free tier, so I can just use Bencher Cloud for my personal projects. And at work where everything needs to be in our private cloud, I’ve started using Bencher Self-Hosted.

Bencher has a built in adapters, so it’s easy to integrate into CI. After following the Quick Start guide, I’m able to run my benchmarks and track them with Bencher.

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

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-8d61ca5a97299729)

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-6896309faf45cd96)
bench_play_game
  Instructions:               38331 (+0.046981%)
  L1 Accesses:                53765 (+0.048382%)
  L2 Accesses:                    6 (-14.28571%)
  RAM Accesses:                  45 (+4.651163%)
  Estimated Cycles:           55370 (+0.164619%)

bench_play_game_100
  Instructions:                 313 (+6.101695%)
  L1 Accesses:                  416 (+6.940874%)
  L2 Accesses:                    2 (No change)
  RAM Accesses:                  13 (No change)
  Estimated Cycles:             881 (+3.161593%)

bench_play_game_1_000_000
  Instructions:                 409 (+4.603581%)
  L1 Accesses:                  512 (+5.567010%)
  L2 Accesses:                    2 (No change)
  RAM Accesses:                  13 (No change)
  Estimated Cycles:             977 (+2.842105%)
    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

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

Using this nifty time travel device that a nice rabbit gave me, I was able to go back in time and replay what would have happened if we were using Bencher all along. You can see where we first pushed the buggy FizzBuzzFibonacci implementation. I immediately got failures in CI as a comment on my pull request. That same day, I fixed the performance bug, getting rid of that needless, extra loop. No fires. Just happy users.

Bencher: Continuous Benchmarking

Bencher is a suite of continuous benchmarking tools. Have you ever had a performance regression impact your users? Bencher could have prevented that from happening. Bencher allows you to detect and prevent performance regressions before they make it to production.

• Run: Run your benchmarks locally or in CI using your favorite benchmarking tools. The bencher CLI simply wraps your existing benchmark harness and stores its results.
• Track: Track the results of your benchmarks over time. Monitor, query, and graph the results using the Bencher web console based on the source branch, testbed, and measure.
• Catch: Catch performance regressions in CI. Bencher uses state of the art, customizable analytics to detect performance regressions before they make it to production.

For the same reasons that unit tests are run in CI to prevent feature regressions, benchmarks should be run in CI with Bencher to prevent performance regressions. Performance bugs are bugs!

Start catching performance regressions in CI — try Bencher Cloud for free.