Como fazer benchmark de código Rust com Criterion

O que é Benchmarking?

Benchmarking é a prática de testar o desempenho do seu código para ver quão rápido (latência) ou quanta (vazão) trabalho ele pode realizar. Esta etapa frequentemente negligenciada no desenvolvimento de software é crucial para criar e manter códigos rápidos e de alto desempenho. O Benchmarking fornece as métricas necessárias para os desenvolvedores entenderem quão bem o seu código se comporta sob diversas cargas de trabalho e condições. Pelos mesmos motivos pelos quais você escreve testes unitários e de integração para prevenir regressões de recursos, você deve escrever benchmarks para prevenir regressões de desempenho. Bugs de desempenho são bugs!

Escreva FizzBuzz em Rust

Para escrevermos testes de desempenho, precisamos de algum código-fonte para testar. Para começar, vamos escrever um programa muito simples, FizzBuzz.

As regras para o FizzBuzz são as seguintes:

Escreva um programa que imprima os inteiros de 1 a 100 (inclusive):

• Para múltiplos de três, imprima Fizz
• Para múltiplos de cinco, imprima Buzz
• Para múltiplos de três e cinco, imprima FizzBuzz
• Para todos os outros, imprima o número

Existem muitas maneiras de escrever o FizzBuzz. Então vamos seguir com o meu favorito:

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

• Crie uma função main
• Itere de 1 a 100 inclusivamente.
• Para cada número, calcule o módulo (resto depois da divisão) para ambos 3 e 5.
• Faça correspondência de padrões nos dois restos. Se o resto é 0, então o número é múltiplo do fator dado.
• Se o resto é 0 para ambos 3 e 5 então imprima FizzBuzz.
• Se o resto é 0 apenas para 3 então imprima Fizz.
• Se o resto é 0 apenas para 5 então imprima Buzz.
• Caso contrário, apenas imprima o número.

Siga Passo a Passo

Para acompanhar este tutorial passo a passo, você precisa instalar Rust.

🐰 O código fonte para esta postagem está disponível no GitHub

Com Rust instalado, você pode então abrir uma janela de terminal e digitar: cargo init game

Em seguida, navegue para o diretório game recém-criado.

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

Você verá um diretório chamado src com um arquivo chamado main.rs:

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

Substitua o conteúdo dele pela implementação FizzBuzz acima. Depois, execute cargo run. A saída deve ser parecida com:

$ 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! Você está arrasando na entrevista de programação!

Um novo arquivo Cargo.lock deve ter sido gerado:

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

Antes de prosseguir, é importante discutir as diferenças entre micro-benchmarking e macro-benchmarking.

Micro-Benchmarking vs Macro-Benchmarking

Existem duas categorias importantes de benchmarks de software: micro-benchmarks e macro-benchmarks. Os micro-benchmarks operam em um nível semelhante aos testes unitários. Por exemplo, um benchmark para uma função que determina Fizz, Buzz, ou FizzBuzz para um número individual seria um micro-benchmark. Os macro-benchmarks operam em um nível semelhante aos testes de integração. Por exemplo, um benchmark para uma função que executa o jogo inteiro de FizzBuzz, de 1 a 100, seria um macro-benchmark.

Em geral, é melhor testar no menor nível de abstração possível. No caso dos benchmarks, isso os torna mais fáceis de manter, e ajuda a reduzir a quantidade de ruído nas medições. No entanto, assim como ter alguns testes de ponta a ponta pode ser muito útil para verificar se todo o sistema se junta conforme esperado, ter macro-benchmarks pode ser muito útil para garantir que os caminhos críticos através do seu software permaneçam com bom desempenho.

Benchmarking em Rust

As três opções populares para benchmarking em Rust são: libtest bench, Criterion, e Iai.

libtest é o framework de testes unitários e benchmarking integrado do Rust. Apesar de fazer parte da biblioteca padrão do Rust, libtest bench ainda é considerado instável, portanto, está disponível apenas em versões de compilador nightly. Para trabalhar no compilador Rust estável, um arnês de benchmarking separado precisa ser usado. No entanto, nenhum dos dois está sendo ativamente desenvolvido.

O arnês de benchmarking mais ativamente mantido dentro do ecossistema Rust é o Criterion. Ele funciona tanto em versões estáveis quanto nightly do compilador Rust, e se tornou o padrão de facto dentro da comunidade Rust. Criterion também é muito mais rico em recursos em comparação com libtest bench.

Uma alternativa experimental ao Criterion é o Iai, do mesmo criador do Criterion. No entanto, ele usa contagens de instrução em vez de tempo de clock de parede: instruções de CPU, acessos L1, acessos L2 e acessos à RAM. Isso permite a realização de benchmarks de tiro único, uma vez que essas métricas devem permanecer quase idênticas entre as execuções.

Todos os três são suportados pelo Bencher. Então, por que escolher o Criterion? Criterion é o padrão de facto para realização de benchmark na comunidade Rust. Eu sugeriria o uso do Criterion para fazer benchmark da latência do seu código. Ou seja, o Criterion é ótimo para medir o tempo de relógio.

Refatorando o FizzBuzz

Para testar nosso aplicativo FizzBuzz, precisamos desacoplar nossa lógica da função main do programa. Os bancos de teste não conseguem benchmarkar a função main. Para fazer isso, precisamos fazer algumas alterações.

Em src, crie um novo arquivo chamado lib.rs:

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

Adicione o seguinte código em 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: Recebe um número inteiro não assinado n, chama fizz_buzz com aquele número, e se print for true imprime o resultado.
• fizz_buzz: Recebe um número inteiro não assinado n e executa a lógica real de Fizz, Buzz, FizzBuzz, ou número retornando o resultado como uma string.

Em seguida, atualize main.rs para ter esta aparência:

use game::play_game;

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

• game::play_game: Importa play_game do pacote game que acabamos de criar com lib.rs.
• main: O ponto de entrada principal em nosso programa que percorre os números de 1 a 100 inclusos e chama play_game para cada número, com print definido como true.

Benchmarking do FizzBuzz

Para fazer benchmark do nosso código, precisamos criar um diretório benches e adicionar um arquivo para conter nossos benchmarks, play_game.rs:

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

Dentro de play_game.rs adicione o seguinte código:

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

• Importe o executor de benchmark Criterion.
• Importe a função play_game da nossa crate game.
• Crie uma função chamada bench_play_game que recebe uma referência mutável para Criterion.
• Use a instância Criterion (c) para criar um benchmark chamado bench_play_game.
• Em seguida, use o executor de benchmark (b) para executar nosso macro-benchmark várias vezes.
• Execute nosso macro-benchmark dentro de uma “caixa preta” para que o compilador não otimize nosso código.
• Itere de 1 a 100 inclusivamente.
• Para cada número, chame play_game, com print definido como false.

Agora precisamos configurar a crate game para executar nossos benchmarks.

Adicione o seguinte ao final do seu arquivo Cargo.toml:

[dev-dependencies]
criterion = "0.5"

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

• criterion: Adicione criterion como uma dependência de desenvolvimento, pois estamos usando apenas para testes de performance.
• bench: Registre play_game como um benchmark e defina harness como false, pois usaremos o Criterion como nossa ferramenta de benchmarking.

Agora estamos prontos para fazer benchmark do nosso código, execute 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

🐰 Vamos agitar a centrífuga! Conseguimos nossas primeiras métricas de benchmark!

Finalmente, podemos descansar nossas cansadas cabeças de desenvolvedores… Brincadeira, nossos usuários querem um novo recurso!

Escreva FizzBuzzFibonacci em Rust

Nossos Indicadores Chave de Desempenho (KPIs) estão em baixa, então nosso Gerente de Produto (PM) quer que adicionemos um novo recurso. Após muitas discussões e várias entrevistas com usuários, decidiu-se que o bom e velho FizzBuzz não é suficiente. As crianças de hoje querem um novo jogo, FizzBuzzFibonacci.

As regras para FizzBuzzFibonacci são as seguintes:

Escreva um programa que imprime os números inteiros de 1 a 100 (inclusive):

• Para múltiplos de três, imprima Fizz
• Para múltiplos de cinco, imprima Buzz
• Para múltiplos de ambos três e cinco, imprima FizzBuzz
• Para números que fazem parte da sequência de Fibonacci, apenas imprima Fibonacci
• Para todos os outros, imprima o número

A Sequência de Fibonacci é uma série na qual cada número é a soma dos dois números precedentes. Por exemplo, começando com 0 e 1 o próximo número na sequência de Fibonacci seria 1. Seguido por: 2, 3, 5, 8 e assim por diante. Números que fazem parte da Sequência de Fibonacci são conhecidos como números de Fibonacci. Então, teremos que escrever uma função que detecte números de Fibonacci.

Existem muitas maneiras de escrever a sequência de Fibonacci e, da mesma forma, muitas maneiras de detectar um número de Fibonacci. Então, vamos com a minha favorita:

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
}

• Crie uma função chamada is_fibonacci_number que recebe um número inteiro sem sinal e retorna um booleano.
• Itere para todos os números de 0 ao nosso número específico n inclusive.
• Inicialize nossa sequência Fibonacci começando com 0 e 1 como os números anterior e atual respectivamente.
• Itere enquanto o número atual for menor que a iteração atual i.
• Adicione o número atual e anterior para obter o número próximo.
• Atualize o número anterior para o número atual.
• Atualize o número atual para o número próximo.
• Uma vez que atual for maior ou igual ao número especifico n, nós sairemos do loop.
• Verifique se o número atual é igual ao número especificado n e, se for, retorne true.
• Caso contrário, retorne false.

Agora precisaremos atualizar nossa função 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(),
        }
    }
}

• Renomeie a função fizz_buzz para fizz_buzz_fibonacci para torná-la mais descritiva.
• Chame nossa função auxiliar is_fibonacci_number.
• Se o resultado de is_fibonacci_number for true retorne Fibonacci.
• Se o resultado de is_fibonacci_number for false, execute a mesma lógica Fizz, Buzz, FizzBuzz, ou número retornando o resultado.

Como renomeamos fizz_buzz para fizz_buzz_fibonacci, também precisamos atualizar nossa função play_game:

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

Ambas as funções main e bench_play_game podem permanecer exatamente as mesmas.

Benchmarking do FizzBuzzFibonacci

Agora podemos reexecutar nosso benchmark:

$ 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

Oh, interessante! O Criterion nos informa que a diferença entre o desempenho dos nossos jogos FizzBuzz e FizzBuzzFibonacci é +568.69%. Seus números serão um pouco diferentes dos meus. No entanto, a diferença entre os dois jogos provavelmente está na faixa de 5x. Isso me parece bom! Especialmente por adicionar um recurso tão sofisticado quanto Fibonacci ao nosso jogo. As crianças vão adorar!

Expandindo FizzBuzzFibonacci em Rust

Nosso jogo é um sucesso! As crianças realmente adoram jogar FizzBuzzFibonacci. Tanto que a direção quer uma sequência. Mas vivemos em um mundo moderno, precisamos de Receita Anual Recorrente (ARR) e não de compras únicas! A nova visão para o nosso jogo é que ele seja aberto, sem mais viver entre os limites de 1 e 100 (mesmo que inclusivo). Não, estamos partindo para novas fronteiras!

As regras para o Open World FizzBuzzFibonacci são as seguintes:

Escreva um programa que aceite qualquer número inteiro positivo e imprima:

• Para múltiplos de três, imprima Fizz
• Para múltiplos de cinco, imprima Buzz
• Para múltiplos de ambos três e cinco, imprima FizzBuzz
• Para números que fazem parte da sequência de Fibonacci, apenas imprima Fibonacci
• Para todos os outros, imprima o número

Para que nosso jogo funcione para qualquer número, precisaremos aceitar um argumento de linha de comando. Atualize a função main para ficar assim:

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

• Colete todos os argumentos (args) passados para o nosso jogo a partir da linha de comando.
• Pegue o primeiro argumento passado para o nosso jogo e analise-o como um inteiro não assinado i.
• Se a análise falhar ou nenhum argumento for passado, use por padrão o nosso jogo com 15 como entrada.
• Finalmente, jogue nosso jogo com o novo inteiro não assinado i analisado.

Agora podemos jogar nosso jogo com qualquer número! Use cargo run seguido de -- para passar argumentos para o nosso jogo:

$ 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

E se omitirmos ou fornecermos um número inválido:

$ 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

Nossa, que teste completo! O CI passou. Nossos chefes estão entusiasmados. Vamos lançá-lo! 🚀

O Fim

🐰 … o fim da sua carreira talvez?

Brincadeira! Tudo está pegando fogo! 🔥

Bem, a princípio, tudo parecia estar indo bem. Então, às 02:07 da madrugada de sábado, meu pager disparou:

📟 Seu jogo está pegando fogo! 🔥

Após sair da cama às pressas, tentei descobrir o que estava acontecendo. Eu tentei pesquisar nos logs, mas era difícil porque tudo continuava travando. Finalmente, encontrei o problema. As crianças! Elas adoravam tanto nosso jogo que jogavam até chegar a um milhão! Num lampejo de brilhantismo, adicionei dois novos benchmarks:

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

• Um micro-benchmark bench_play_game_100 para jogar o jogo com o número cem (100)
• Um micro-benchmark bench_play_game_1_000_000 para jogar o jogo com o número um milhão (1_000_000)

Quando executei, obtive isto:

$ 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

Aguarde… aguarde…

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

O quê! 403,57 ns x 1,000 deveria ser 403.570 ns e não 9,596,800 ns (9.5968 ms x 1_000_000 ns/1 ms) 🤯 Mesmo que eu tenha meu código da sequência de Fibonacci funcionando corretamente, devo ter algum bug de desempenho nele.

Corrigindo FizzBuzzFibonacci em Rust

Vamos dar outra olhada naquela função 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
}

Agora que estou pensando em desempenho, percebo que tenho um loop extra desnecessário. Podemos nos livrar completamente do loop for i in 0..=n {} e apenas comparar o valor atual com o número dado (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
}

• Atualize sua função is_fibonacci_number.
• Inicialize nossa sequência de Fibonacci começando com 0 e 1 como os números anterior e atual, respectivamente.
• Itere enquanto o número atual for menor que o número dado n.
• Adicione o número anterior e atual para obter o número próximo.
• Atualize o número anterior para o número atual.
• Atualize o número atual para o número próximo.
• Uma vez que atual seja maior ou igual ao número dado n, sairemos do loop.
• Verifique se o número atual é igual ao número dado n e retorne esse resultado.

Agora vamos reexecutar esses benchmark e ver como nos saímos:

$ 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

Oh, uau! Nosso benchmark bench_play_game voltou para algo próximo de onde estava para o FizzBuzz original. Eu queria lembrar exatamente qual era esse score. Mas já se passaram três semanas. Meu histórico de terminal não vai tão longe. E o Criterion só compara com o resultado mais recente. Mas acho que está perto!

O benchmark bench_play_game_100 está quase 10x para baixo, -93.950%. E o benchmark bench_play_game_1_000_000 está mais de 10,000x para baixo! 9,596,800 ns para 30.403 ns! Nós até maximizamos o medidor de mudança do Criterion, que só vai até -100.000%!

🐰 Ei, pelo menos pegamos este bug de desempenho antes de ir para a produção… ah, certo. Esqueça…

Detecte Regressões de Desempenho em CI

Os executivos não ficaram felizes com a enxurrada de críticas negativas que nosso jogo recebeu devido ao meu pequeno bug de desempenho. Eles me disseram para não deixar isso acontecer de novo, e quando perguntei como, eles simplesmente me disseram para não fazê-lo novamente. Como eu deveria gerenciar isso‽

Felizmente, encontrei esta incrível ferramenta open source chamada Bencher. Existe um nível gratuito super generoso, então posso apenas usar Bencher Cloud para meus projetos pessoais. E no trabalho, onde tudo precisa estar em nossa nuvem privada, comecei a usar Bencher Auto-Hospedado.

Bencher tem adaptadores integrados, por isso é fácil de integrar ao CI. Após seguir o guia Rápido Início, consegui executar meus benchmarks e rastreá-los com o 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

Usando este incrível dispositivo de viagem no tempo que um simpático coelho me deu, consegui voltar ao passado e reviver o que teria acontecido se estivéssemos usando o Bencher desde o início. Você pode ver onde fizemos pela primeira vez o push da implementação bugada de FizzBuzzFibonacci. Imediatamente recebi falhas no CI como um comentário na minha solicitação de pull. No mesmo dia, corrigi o bug de desempenho, eliminando aquele loop extra e desnecessário. Sem incêndios. Apenas usuários felizes.

Bencher: Benchmarking Contínuo

Bencher é um conjunto de ferramentas de benchmarking contínuas. Já teve algum impacto de regressão de desempenho nos seus usuários? Bencher poderia ter prevenido isso. Bencher permite que você detecte e previna regressões de desempenho antes que cheguem à produção.

• Execute: Execute seus benchmarks localmente ou no CI usando suas ferramentas de benchmarking favoritas. O CLI bencher simplesmente envolve seu harness de benchmark existente e armazena seus resultados.
• Rastreie: Acompanhe os resultados de seus benchmarks ao longo do tempo. Monitore, consulte e faça gráficos dos resultados usando o console web do Bencher baseado na branch de origem, testbed e medida.
• Capture: Capture regressões de desempenho no CI. Bencher usa análises personalizáveis e de última geração para detectar regressões de desempenho antes que elas cheguem à produção.

Pelos mesmos motivos que os testes de unidade são executados no CI para prevenir regressões de funcionalidades, benchmarks deveriam ser executados no CI com o Bencher para prevenir regressões de desempenho. Bugs de desempenho são bugs!

Comece a capturar regressões de desempenho no CI — experimente o Bencher Cloud gratuitamente.