Cómo hacer pruebas de rendimiento en Rust con el banco de pruebas libtest

¿Qué es el Benchmarking?

El benchmarking es la práctica de probar el rendimiento de tu código para ver qué tan rápido (latencia) o cuánto (rendimiento) trabajo puede hacer. Este paso a menudo olvidado en el desarrollo de software es crucial para crear y mantener un código rápido y de alto rendimiento. El benchmarking proporciona las métricas necesarias para que los desarrolladores comprendan qué tan bien se desempeña su código bajo diversas cargas de trabajo y condiciones. Por las mismas razones que escribes pruebas unitarias y de integración para prevenir regresiones de características, debes escribir benchmarks para prevenir regresiones de rendimiento. ¡Los errores de rendimiento son errores!

Escribe FizzBuzz en Rust

Para escribir evaluaciones comparativas, necesitamos algún código fuente para comparar. Para empezar, vamos a escribir un programa muy simple, FizzBuzz.

Las reglas para FizzBuzz son las siguientes:

Escribe un programa que imprima los números enteros del 1 al 100 (incluyendo ambos):

• Para múltiplos de tres, imprime Fizz
• Para múltiplos de cinco, imprime Buzz
• Para múltiplos de ambos, tres y cinco, imprime FizzBuzz
• Para todos los demás, imprime el número

Hay muchas formas de escribir FizzBuzz. Así que vamos a elegir mi favorita:

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

• Crea una función main
• Itera desde 1 hasta 100 de manera inclusiva.
• Para cada número, calcula el módulo (resto después de la división) tanto para 3 como para 5.
• Coincide el patrón con los dos restos. Si el resto es 0, entonces el número es múltiplo del factor dado.
• Si el resto es 0 tanto para 3 como para 5, imprime FizzBuzz.
• Si el resto es 0 solo para 3, entonces imprime Fizz.
• Si el resto es 0 solo para 5, entonces imprime Buzz.
• De lo contrario, simplemente imprime el número.

Sigue Paso a Paso

Para seguir este tutorial paso a paso, necesitarás instalar Rust.

🐰 El código fuente de esta publicación está disponible en GitHub

Con Rust instalado, puedes abrir una ventana de terminal e introducir: cargo init game

Luego navega hacia el directorio game recién creado.

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

Deberías ver un directorio llamado src con un archivo llamado main.rs:

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

Reemplaza sus contenidos con la implementación de FizzBuzz de arriba. Luego ejecuta cargo run. La salida debería verse así:

$ 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! ¡Estás rompiendo la entrevista de codificación!

Se debería haber generado un nuevo archivo Cargo.lock:

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

Antes de avanzar más, es importante discutir las diferencias entre micro-benchmarking y macro-benchmarking.

Micro-Benchmarking vs Macro-Benchmarking

Existen dos categorías principales de benchmarks de software: micro-benchmarks y macro-benchmarks. Los micro-benchmarks operan a un nivel similar a las pruebas unitarias. Por ejemplo, un benchmark para una función que determina Fizz, Buzz, o FizzBuzz para un único número sería un micro-benchmark. Los macro-benchmarks operan a un nivel similar a las pruebas de integración. Por ejemplo, un benchmark para una función que juega el juego completo de FizzBuzz, desde 1 hasta 100, sería un macro-benchmark.

Generalmente, es mejor probar al nivel más bajo de abstracción posible. En el caso de los benchmarks, esto los hace más fáciles de mantener, y ayuda a reducir la cantidad de ruido en las mediciones. Sin embargo, al igual que tener algunas pruebas de extremo a extremo puede ser muy útil para verificar la cordura todo el sistema se junta como se esperaba, tener macro-benchmarks puede ser muy útil para asegurarse de que los caminos críticos a través de su software se mantienen con buen rendimiento.

Benchmarking en Rust

Las tres opciones populares para el benchmarking en Rust son: libtest bench, Criterion, y Iai.

libtest es el marco de pruebas unitarias y benchmarking incorporado en Rust. Aunque es parte de la librería estándar de Rust, libtest bench aún se considera inestable, por lo que solo está disponible en las versiones nightly del compilador. Para trabajar en el compilador estable de Rust, se necesita usar un arnés de benchmarking separado. Sin embargo, ninguno de los dos está en desarrollo activo.

El arnés de benchmarking más activamente mantenida dentro del ecosistema de Rust es Criterion. Funciona tanto con las versiones de compilador estables como nightly de Rust, y se ha convertido en el estándar dentro de la comunidad de Rust. Criterion también es mucho más rico en características en comparación con libtest bench.

Una alternativa experimental a Criterion es Iai, del mismo creador que Criterion. Sin embargo, utiliza recuentos de instrucciones en lugar de tiempo de reloj de pared: instrucciones de CPU, accesos a L1, accesos a L2 y accesos a RAM. Esto permite el benchmarking de disparo único, ya que estas métricas deberían permanecer casi idénticas entre ejecuciones.

Los tres son soportados por Bencher. Entonces, ¿por qué elegir banco de pruebas libtest? Puede ser una buena idea si estás tratando de limitar las dependencias externas de tu proyecto y tu proyecto ya está usando la cadena de herramientas nightly. Fuera de eso, sugeriría usar Criterion o Iai dependiendo de tu caso de uso.

Instalar Rust nightly

Dicho esto, vamos a usar el banco de pruebas libtest, así que vamos a poner nuestra cadena de herramientas de Rust en nightly. Crea un archivo rust-toolchain.toml en la raíz de tu proyecto game, junto a Cargo.toml.

[toolchain]
channel = "nightly"

Tu estructura de directorios ahora debería lucir así:

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

Una vez que esté completo, vuelve a ejecutar cargo run. Debería llevar un minuto para que la nueva cadena de herramientas nightly se instale antes de volver a ejecutar y darte la misma salida que antes.

Refactorizar FizzBuzz

Para probar nuestra aplicación FizzBuzz, necesitamos desacoplar nuestra lógica de la función main del programa. Las superestructuras de rendimiento no pueden medir el rendimiento de la función main.

Actualiza tu código para que se vea así:

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

Ahora hemos separado nuestro código en tres funciones diferentes:

• main: El punto de entrada principal a nuestro programa que itera a través de los números del 1 al 100, inclusive, y llama a play_game para cada número.
• play_game: Toma un número entero sin signo n, llama a fizz_buzz con ese número, e imprime el resultado.
• fizz_buzz: Toma un número entero sin signo n y realiza la lógica de Fizz, Buzz, FizzBuzz o número, devolviendo el resultado como una cadena.

Haciendo benchmark de FizzBuzz

Para utilizar el inestable crate libtest necesitamos habilitar la feature test para nuestro código e importar el crate test. Añade lo siguiente en la parte superior de main.rs:

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

¡Ahora estamos listos para añadir nuestro primer benchmark! Añade lo siguiente en la parte inferior 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)
            });
        });
    }
}

• Crea un módulo llamado benchmarks y establece la configuración del compilador a modo test.
• Importa el runner de benchmark Bencher. (🐰 ¡Hey, qué nombre tan cool!)
• Importa nuestra función play_game.
• Crea un benchmark llamado bench_play_game que recibe una referencia mutable a Bencher.
• Establece el atributo #[bench] para indicar que bench_play_game es un benchmark.
• Usa la instancia Bencher (b) para ejecutar nuestro macro-benchmark varias veces.
• Ejecuta nuestro macro-benchmark dentro de una “caja negra” para que el compilador no optimice nuestro código.
• Itera desde 1 hasta 100 inclusive.
• Para cada número, llama a play_game.

Ahora estamos listos para hacer un benchmark de nuestro código, ejecuta 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

🐰 ¡Encendamos el ritmo! ¡Tenemos nuestras primeras métricas de benchmark!

Finalmente, podemos descansar nuestras cansadas cabezas de desarrolladores… Sólo bromeaba, ¡nuestros usuarios quieren una nueva función!

Escribe FizzBuzzFibonacci en Rust

Nuestros Indicadores Clave de Desempeño (KPIs) están bajos, por lo que nuestro Gerente de Producto (PM) quiere que agreguemos una nueva función. Después de mucho lluvia de ideas y muchas entrevistas con usuarios, se decidió que el FizzBuzz de siempre no es suficiente. Los niños de hoy en día quieren un nuevo juego, FizzBuzzFibonacci.

Las reglas para FizzBuzzFibonacci son las siguientes:

Escribe un programa que imprima los enteros del 1 al 100 (inclusive):

• Para múltiplos de tres, imprime Fizz
• Para múltiplos de cinco, imprime Buzz
• Para múltiplos de tres y cinco, imprime FizzBuzz
• Para números que sean parte de la secuencia de Fibonacci, solo imprime Fibonacci
• Para todos los demás, imprime el número

La secuencia de Fibonacci es una serie en la que cada número es la suma de los dos números anteriores. Por ejemplo, comenzando con 0 y 1 el siguiente número en la secuencia de Fibonacci sería 1. Seguido de: 2, 3, 5, 8 y así sucesivamente. Los números que forman parte de la secuencia de Fibonacci se conocen como números de Fibonacci. Por lo tanto, tendremos que escribir una función que detecte los números de Fibonacci.

Hay muchas formas de escribir la secuencia de Fibonacci y de igual forma muchas maneras de detectar un número de Fibonacci. Así que elegiremos mi forma 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
}

• Crea una función llamada is_fibonacci_number que toma un número entero sin signo y devuelve un booleano.
• Itera para todos los números desde 0 hasta nuestro número dado n inclusive.
• Inicializa nuestra secuencia Fibonacci comenzando con 0 y 1 como los números anterior y actual respectivamente.
• Itera mientras el número actual sea menor que la iteración actual i.
• Suma el número anterior y el número actual para obtener el número siguiente.
• Actualiza el número anterior al número actual.
• Actualiza el número actual al número siguiente.
• Una vez que actual sea mayor o igual al número dado n, saldremos del bucle.
• Verifica si el número actual es igual al número dado n y si es así, devuelve true.
• De lo contrario, devuelve false.

Ahora necesitaremos actualizar nuestra función 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(),
        }
    }
}

• Renombra la función fizz_buzz a fizz_buzz_fibonacci para que sea más descriptiva.
• Llama a nuestra función auxiliar is_fibonacci_number.
• Si el resultado de is_fibonacci_number es true, entonces devuelve Fibonacci.
• Si el resultado de is_fibonacci_number es false, entonces realiza la misma lógica de Fizz, Buzz, FizzBuzz o número devolviendo el resultado.

Debido a que renombramos fizz_buzz a fizz_buzz_fibonacci también necesitamos actualizar nuestra función play_game:

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

Tanto nuestras funciones main como bench_play_game pueden permanecer exactamente iguales.

Haciendo Benchmark de FizzBuzzFibonacci

Ahora podemos volver a ejecutar nuestro 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

Desplazándonos hacia atrás a través de nuestro historial de terminal, podemos hacer una comparación visual entre el rendimiento de nuestros juegos FizzBuzz y FizzBuzzFibonacci: 4,879 ns vs 22,167 ns. Tus números serán un poco diferentes a los míos. Sin embargo, la diferencia entre los dos juegos probablemente sea de alrededor de 5 veces. ¡Eso me parece bien! Especialmente por agregar una función tan sofisticada como Fibonacci a nuestro juego. ¡A los niños les encantará!

Expande FizzBuzzFibonacci en Rust

¡Nuestro juego es todo un éxito! A los niños definitivamente les encanta jugar FizzBuzzFibonacci. Tanto así que llegó la noticia de los ejecutivos de que quieren una secuela. Pero este es el mundo moderno, ¡necesitamos ingresos recurrentes anuales (ARR) no compras únicas! La nueva visión para nuestro juego es que sea abierto, ¡no más limitaciones entre el 1 y el 100 (aunque sea inclusivo)! ¡No, vamos hacia nuevas fronteras!

Las reglas para Open World FizzBuzzFibonacci son las siguientes:

Escribe un programa que tome cualquier número entero positivo e imprima:

• Para múltiplos de tres, imprime Fizz
• Para múltiplos de cinco, imprime Buzz
• Para múltiplos de tres y cinco, imprime FizzBuzz
• Para números que son parte de la secuencia Fibonacci, sólo imprime Fibonacci
• Para todos los demás, imprime el número

Para que nuestro juego funcione con cualquier número, necesitaremos aceptar un argumento de línea de comandos. Actualiza la función main para que se vea así:

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

• Recolecta todos los argumentos (args) pasados a nuestro juego desde la línea de comandos.
• Obtén el primer argumento pasando a nuestro juego y analízalo como un entero sin signo i.
• Si el análisis falla o no se pasa ningún argumento, por defecto, nuestro juego tomará el 15 como entrada.
• Finalmente, juega nuestro juego con el nuevo entero sin signo i.

¡Ahora podemos jugar nuestro juego con cualquier número! Usa cargo run seguido de -- para pasar argumentos a nuestro juego:

$ 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

Y si omitimos o proporcionamos un 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

Vaya, ¡eso fue una prueba exhaustiva! CI pasa. Nuestros jefes están emocionados. ¡Vamos a lanzarlo! 🚀

El Fin

🐰 … ¿el fin de tu carrera tal vez?

¡Solo bromeaba! ¡Todo está en llamas! 🔥

Bueno, al principio todo parecía ir bien. Y luego a las 02:07 AM del sábado, mi buscapersonas sonó:

📟 ¡Tu juego está en llamas! 🔥

Después de salir de la cama a la carrera, traté de averiguar qué estaba pasando. Intenté buscar en los registros, pero eso fue difícil porque todo seguía fallando. Finalmente, encontré el problema. ¡Los niños! Les encantaba tanto nuestro juego, que lo estaban jugando hasta llegar al millón! En un destello de genialidad, agregué dos nuevos 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)));
}

• Un micro-benchmark bench_play_game_100 para jugar el juego con el número cien (100)
• Un micro-benchmark bench_play_game_1_000_000 para jugar el juego con el número un millón (1_000_000)

Cuando lo ejecuté, obtuve esto:

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

Espéralo… espéralo…

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

¡Qué! 439 ns x 1,000 debería ser 439,000 ns no 9,586,977 ns 🤯 Aunque obtuve mi función de código de secuencia de Fibonacci funcionalmente correcta, debo tener un error de rendimiento en algún lugar.

Corrección de FizzBuzzFibonacci en Rust

Volviendo a mirar la función 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
}

Ahora que estoy pensando en el rendimiento, me doy cuenta de que tengo un ciclo extra innecesario. Podemos deshacernos por completo del bucle for i in 0..=n {} y simplemente comparar el valor current con el 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
}

• Actualiza tu función de is_fibonacci_number.
• Inicializa nuestra secuencia de Fibonacci comenzando con el 0 y 1 como los números previous y current respectivamente.
• Itera mientras que el número current sea menor al número dado n.
• Suma el número previous y current para obtener el número next.
• Actualiza el número previous al número current.
• Actualiza el número current al número next.
• Una vez que current es mayor o igual al número dado n, saldremos del bucle.
• Comprobar si el número current es igual al número dado n y devolver ese resultado.

Ahora vamos a volver a ejecutar esas pruebas y ver cómo nos fue:

$ 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

¡Oh, vaya! Nuestro benchmark bench_play_game ha vuelto a estar cerca de donde estaba para el original FizzBuzz. Ojalá pudiera recordar exactamente cuál era esa puntuación. Han pasado tres semanas. Mi historial de terminal no llega tan lejos. ¡Pero creo que está cerca!

El benchmark bench_play_game_100 ha bajado casi 10 veces, de 439 ns a 46 ns. ¡Y el benchmark bench_play_game_1_000_000 ha bajado más de 10,000 veces! ¡De 9,586,977 ns a 53 ns!

🐰 Hey, al menos detectamos este error de rendimiento antes de que llegara a producción… oh, cierto. No importa…

Detectar Retrocesos de Rendimiento en CI

Los ejecutivos no estaban contentos con la avalancha de críticas negativas que recibió nuestro juego debido a mi pequeño error de rendimiento. Me dijeron que no dejara que volviera a ocurrir, y cuando les pregunté cómo, simplemente me dijeron que no volviera a hacerlo. ¡¿Cómo se supone que debería manejar eso‽

Afortunadamente, he encontrado esta increíble herramienta de código abierto llamada Bencher. Hay un nivel gratuito súper generoso, así que puedo usar Bencher Cloud para mis proyectos personales. Y en el trabajo, donde todo debe estar en nuestra nube privada, he comenzado a usar Bencher Self-Hosted.

Bencher tiene adaptadores incorporados, por lo que es fácil de integrar en CI. Después de seguir la guía de inicio rápido, ya puedo ejecutar mis referencias y seguir su progreso con 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 práctico dispositivo de viaje en el tiempo que un amable conejo me dio, pude retroceder en el tiempo y reproducir lo que habría sucedido si hubiéramos estado utilizando Bencher todo el tiempo. Puedes ver dónde publicamos por primera vez la implementación defectuosa de FizzBuzzFibonacci. Inmediatamente recibí fallas en CI como un comentario en mi solicitud de extracción. Ese mismo día, arreglé el error de rendimiento, eliminando ese bucle extra innecesario. No hubo incendios. Solo usuarios contentos.

Bencher: Benchmarking continuo

Bencher es un conjunto de herramientas de benchmarking continuo. ¿Alguna vez has tenido un impacto de regresión de rendimiento en tus usuarios? Bencher podría haber evitado que eso sucediera. Bencher te permite detectar y prevenir las regresiones de rendimiento antes de que lleguen a producción.

• Ejecutar: Ejecute sus benchmarks localmente o en CI usando sus herramientas de benchmarking favoritas. La CLI bencher simplemente envuelve su arnés de benchmarks existente y almacena sus resultados.
• Seguir: Sigue los resultados de tus benchmarks con el tiempo. Monitoriza, realiza consultas y representa gráficamente los resultados utilizando la consola web de Bencher basándose en la rama de origen, el banco de pruebas y la medida.
• Capturar: Captura las regresiones de rendimiento en CI. Bencher utiliza analíticas de vanguardia y personalizables para detectar regresiones de rendimiento antes de que lleguen a producción.

Por las mismas razones que las pruebas unitarias se ejecutan en CI para prevenir regresiones funcionales, los benchmarks deberían ejecutarse en CI con Bencher para prevenir regresiones de rendimiento. ¡Los errores de rendimiento son errores!

Empiece a capturar regresiones de rendimiento en CI — prueba Bencher Cloud gratis.