Como fazer benchmark de código Rust com libtest bench

Everett Pompeii

O que é Benchmarking?

Benchmarking é a prática de testar o desempenho do seu código para ver quão rápido (latência) ou quanto (throughput) trabalho ele pode executar. Este passo frequentemente negligenciado no desenvolvimento de software é crucial para criar e manter um código rápido e performático. O benchmarking fornece as métricas necessárias para que os desenvolvedores compreendam o desempenho do seu código sob várias cargas de trabalho e condições. Pelas mesmas razões que você escreve testes unitários e de integração para evitar regressões de funcionalidades, você deve escrever benchmarks para evitar 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 embutido de testes unitários e benchmarking do Rust. Embora faça parte da biblioteca padrão do Rust, o libtest bench ainda é considerado instável, portanto, está disponível apenas em versões do compilador nightly. Para funcionar no compilador Rust estável, um harness de benchmarking separado precisa ser usado. Nenhum dos dois está sendo desenvolvido ativamente, no entanto.

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

Uma alternativa experimental ao Criterion é o Iai, do mesmo criador do Criterion. No entanto, ele usa contagem de instruções em vez de tempo real: instruções da CPU, acessos L1, acessos L2 e acessos à RAM. Isso permite benchmarking 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 libtest bench? Pode ser uma boa ideia se você está tentando limitar as dependências externas do seu projeto e o seu projeto já está a utilizando a toolchain nightly. Fora isso, eu sugiro o uso do Criterion ou do Iai, dependendo do seu caso de uso.

Instalar o Rust nightly

Dito isso, vamos usar o libtest bench, então vamos configurar nossa toolchain do Rust para nightly. Crie um arquivo rust-toolchain.toml na raiz do seu projeto game, ao lado de Cargo.toml.

[toolchain]
channel = "nightly"

A estrutura do seu diretório agora deve se parecer com isso:

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

Após a conclusão, execute novamente cargo run. Deve levar um minuto para a nova toolchain nightly ser instalada antes de ser executada novamente e fornecer a mesma saída de antes.

Refatoração do FizzBuzz

Para testar nossa aplicação FizzBuzz, precisamos desacoplar nossa lógica da função main do programa. Os bancos de teste não conseguem testar a função main.

Atualize seu código para ficar assim:

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

Agora, separamos nosso código em três funções diferentes:

• main: A entrada principal do nosso programa que itera pelos números de 1 a 100 inclusivo e chama play_game para cada número.
• play_game: Recebe um inteiro não assinado n, chama fizz_buzz com esse número e imprime o resultado.
• fizz_buzz: Recebe um inteiro não assinado n e realiza a lógica Fizz, Buzz, FizzBuzz, ou número retornando o resultado como uma string.

Benchmarking FizzBuzz

Para usar a crate libtest instável, precisamos habilitar o recurso test para o nosso código e importar a crate test. Adicione o seguinte no topo de main.rs:

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

Agora estamos prontos para adicionar nosso primeiro benchmark! Adicione o seguinte no final de 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)
            });
        });
    }
}

• Crie um módulo chamado benchmarks e defina a configuração do compilador para o modo test.
• Importe o executor de benchmarks Bencher. (🐰 Que nome legal!)
• Importe nossa função play_game.
• Crie um benchmark chamado bench_play_game que recebe uma referência mutável para Bencher.
• Defina o atributo #[bench] para indicar que bench_play_game é um benchmark.
• Use a instância Bencher (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 de forma inclusiva.
• Para cada número, chame play_game.

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

🐰 Vamos agitar o pé de alface! Temos 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) {
    println!("{}", fizz_buzz_fibonacci(n));
}

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

Benchmarking FizzBuzzFibonacci

Agora podemos executar novamente nosso benchmark:

$ 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

Vendo nosso histórico no terminal, podemos fazer uma comparação visual entre o desempenho dos nossos jogos FizzBuzz e FizzBuzzFibonacci: 4,879 ns vs 22,167 ns. 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. Parece bom para mim! Especialmente por adicionarmos um recurso com um nome tão sofisticado como 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);
}

• 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:

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

• 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 eu executei, eu obtive isso:

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

Espere por isso… espere por isso…

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

O quê! 439 ns x 1,000 deveria ser 439,000 ns e não 9,586,977 ns 🤯 Mesmo eu tendo acertado meu código da sequência Fibonacci funcionalmente, devo ter algum bug de desempenho por aí.

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 executar novamente esses benchmarks e ver como nós nos saímos:

$ 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

Nossa! Nosso benchmark bench_play_game está de volta aonde estava para o FizzBuzz original. Eu queria lembrar exatamente qual era a pontuação. Já se passaram três semanas. O histórico do meu terminal não vai tão longe. Mas acho que está perto!

O benchmark bench_play_game_100 caiu quase 10x, de 439 ns para 46 ns. E o benchmark bench_play_game_1_000_000 caiu mais de 10,000x! De 9,586,977 ns para 53 ns!

🐰 Pelo menos pegamos esse bug de desempenho antes de ir para produção… ah, certo. Esquece…

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.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

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.