Comment mettre en benchmark le code Rust avec le banc d'essai libtest

Everett Pompeii

Qu’est-ce que le Benchmarking ?

Le benchmarking est la pratique consistant à tester les performances de votre code pour voir à quelle vitesse (latence) ou combien (débit) de travail il peut effectuer. Cette étape souvent négligée dans le développement logiciel est cruciale pour créer et maintenir un code rapide et performant. Le benchmarking fournit les métriques nécessaires aux développeurs pour comprendre comment leur code se comporte sous diverses charges de travail et conditions. Pour les mêmes raisons que vous écrivez des tests unitaires et d’intégration pour éviter les régressions de fonctionnalités, vous devriez écrire des benchmarks pour éviter les régressions de performances. Les bugs de performance sont des bugs !

Écrire FizzBuzz en Rust

Pour écrire des benchmarks, nous avons besoin de code source à évaluer. Pour commencer, nous allons écrire un programme très simple, FizzBuzz.

Les règles pour FizzBuzz sont les suivantes :

Écrivez un programme qui imprime les entiers de 1 à 100 (inclus) :

• Pour les multiples de trois, imprimez Fizz
• Pour les multiples de cinq, imprimez Buzz
• Pour les multiples de trois et de cinq, imprimez FizzBuzz
• Pour tous les autres, imprimez le numéro

Il existe de nombreuses façons d’écrire FizzBuzz. Nous allons donc choisir ma préférée :

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

• Créer une fonction main
• Itérer de 1 à 100 inclusivement.
• Pour chaque nombre, calculez le modulo (reste après division) pour 3 et 5.
• Utilisez le pattern matching sur les deux restes. Si le reste est 0, alors le nombre est un multiple du facteur donné.
• Si le reste est 0 pour 3 et 5, alors imprimez FizzBuzz.
• Si le reste est 0 pour seulement 3, alors imprimez Fizz.
• Si le reste est 0 pour seulement 5, alors imprimez Buzz.
• Sinon, imprimez simplement le nombre.

Suivre étape par étape

Pour suivre ce tutoriel étape par étape, vous devrez installer Rust.

🐰 Le code source de ce post est disponible sur GitHub

Avec Rust installé, vous pouvez alors ouvrir une fenêtre de terminal et entrer : cargo init game

Ensuite, naviguez dans le nouveau répertoire game créé.

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

Vous devriez voir un répertoire appelé src avec un fichier nommé main.rs :

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

Remplacez son contenu par l’implémentation FizzBuzz ci-dessus. Puis exécutez cargo run. Le résultat devrait ressembler à :

$ 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

🐰 Bam ! Vous craquez l’entretien de codage !

Un nouveau fichier Cargo.lock devrait avoir été généré :

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

Avant de continuer, il est important de discuter des différences entre le micro-benchmarking et le macro-benchmarking.

Micro-Benchmarking vs Macro-Benchmarking

Il existe deux grandes catégories de benchmarks logiciels : les micro-benchmarks et les macro-benchmarks. Les micro-benchmarks fonctionnent à un niveau similaire aux tests unitaires. Par exemple, un benchmark pour une fonction qui détermine Fizz, Buzz, ou FizzBuzz pour un seul nombre serait un micro-benchmark. Les macro-benchmarks fonctionnent à un niveau similaire aux tests d’intégration. Par exemple, un benchmark pour une fonction qui joue l’ensemble du jeu de FizzBuzz, de 1 à 100, serait un macro-benchmark.

Généralement, il est préférable de tester au niveau le plus bas d’abstraction possible. Dans le cas des benchmarks, cela les rend à la fois plus faciles à maintenir, et cela aide à réduire le bruit dans les mesures. Cependant, tout comme avoir des tests de bout en bout peut être très utile pour vérifier la cohérence de l’ensemble du système tel que prévu, avoir des macro-benchmarks peut être très utile pour s’assurer que les chemins critiques à travers votre logiciel restent performants.

Benchmarking en Rust

Les trois options populaires pour le benchmarking en Rust sont : libtest bench, Criterion, et Iai.

libtest est le framework intégré de tests unitaires et de benchmarking de Rust. Bien qu’il fasse partie de la bibliothèque standard de Rust, libtest bench est encore considéré comme instable, il n’est donc disponible que sur les versions nightly du compilateur. Pour fonctionner sur le compilateur Rust stable, un harnais de benchmarking séparé doit être utilisé. Cependant, aucun des deux n’est activement développé.

Le harnais de benchmarking le plus populaire dans l’écosystème Rust est Criterion. Il fonctionne à la fois sur les versions stables et nightly du compilateur Rust, et il est devenu le standard de facto au sein de la communauté Rust. Criterion est également beaucoup plus riche en fonctionnalités comparé à libtest bench.

Une alternative expérimentale à Criterion est Iai, créé par le même auteur que Criterion. Cependant, il utilise des comptes d’instructions plutôt que du temps d’horloge murale : instructions CPU, accès L1, accès L2 et accès RAM. Cela permet un benchmarking en une seule passe puisque ces métriques devraient rester quasiment identiques entre les exécutions.

Tous trois sont supportés par Bencher. Alors pourquoi choisir le banc d’essai libtest ? Cela peut être une bonne idée si vous essayez de limiter les dépendances externes de votre projet et que votre projet utilise déjà la chaîne d’outils nightly. En dehors de cela, je suggérerais d’utiliser soit Criterion soit Iai selon votre cas d’utilisation.

Installer Rust nightly

Cela dit, nous allons utiliser le banc d’essai libtest, alors réglons notre chaîne d’outils Rust sur nightly. Créez un fichier rust-toolchain.toml à la racine de votre projet game, à côté de Cargo.toml.

[toolchain]
channel = "nightly"

La structure de votre répertoire devrait maintenant ressembler à ceci :

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

Une fois cela fini, relancez cargo run. Il faudra une minute pour que la nouvelle chaîne d’outils nightly s’installe avant de redémarrer et de vous donner la même sortie qu’auparavant.

Refactorisation FizzBuzz

Pour tester notre application FizzBuzz, nous devons découpler notre logique de la fonction principale main du programme. Les harnais de test ne peuvent pas évaluer la fonction main.

Mettez à jour votre code pour qu’il ressemble à ceci :

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

Nous avons maintenant séparé notre code en trois fonctions différentes :

• main : L’entrée principale dans notre programme qui parcourt les nombres de 1 à 100 inclus et appelle play_game pour chaque nombre.
• play_game : Prend un entier non signé n, appelle fizz_buzz avec ce nombre et imprime le résultat.
• fizz_buzz : Prend un entier non signé n et effectue la logique réelle Fizz, Buzz, FizzBuzz, ou le nombre renvoie le résultat sous forme de chaîne.

Benchmarking de FizzBuzz

Pour utiliser la crate libtest instable, nous devons activer la fonction test pour notre code et importer la crate test. Ajoutez ce qui suit au tout début de main.rs :

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

Maintenant nous sommes prêts à ajouter notre premier benchmark ! Ajoutez ce qui suit au tout bas 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)
            });
        });
    }
}

• Créez un module appelé benchmarks et réglez la configuration du compilateur sur le mode test.
• Importez le runner de benchmark Bencher. (🐰 Hé, cool nom !)
• Importez notre fonction play_game.
• Créez un benchmark appelé bench_play_game qui prend en entrée une référence mutable à Bencher.
• Configurez l’attribut #[bench] pour indiquer que bench_play_game est un benchmark.
• Utilisez l’instance de Bencher (b) pour exécuter plusieurs fois notre macro-benchmark.
• Exécutez notre macro-benchmark à l’intérieur d’une “boîte noire” pour que le compilateur n’optimise pas notre code.
• Itérez de 1 à 100 inclusivement.
• Pour chaque nombre, appelez play_game.

Maintenant nous sommes prêts pour benchmark notre code, exécutez 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

🐰 Laissons la betterave monter ! Nous avons nos premières mesures de benchmark !

Finalement, nous pouvons reposer nos têtes de développeurs fatigués… Juste une blague, nos utilisateurs veulent une nouvelle fonctionnalité !

Écrire FizzBuzzFibonacci en Rust

Nos indicateurs de performance clés (KPIs) sont en baisse, donc notre chef de produit (PM) veut que nous ajoutions une nouvelle fonctionnalité. Après beaucoup de brainstorming et de nombreuses interviews d’utilisateurs, il est décidé que le bon vieux FizzBuzz ne suffit pas. Les gens d’aujourd’hui veulent un nouveau jeu, FizzBuzzFibonacci.

Les règles du FizzBuzzFibonacci sont les suivantes :

Écrivez un programme qui imprime les entiers de 1 à 100 (inclus) :

• Pour les multiples de trois, imprimez Fizz
• Pour les multiples de cinq, imprimez Buzz
• Pour les multiples de trois et cinq, imprimez FizzBuzz
• Pour les nombres qui font partie de la séquence de Fibonacci, imprimez uniquement Fibonacci
• Pour tous les autres, imprimez le nombre

La séquence de Fibonacci est une séquence dans laquelle chaque nombre est la somme des deux précédents. Par exemple, en commençant par 0 et 1, le prochain nombre dans la séquence de Fibonacci serait 1. Suivi par : 2, 3, 5, 8 et ainsi de suite. Les nombres qui font partie de la séquence de Fibonacci sont connus sous le nom de nombres de Fibonacci. Nous allons donc devoir écrire une fonction qui détecte les nombres de Fibonacci.

Il y a plusieurs façons de générer la séquence de Fibonacci et plusieurs façons de détecter un nombre de Fibonacci. Nous allons donc choisir ma méthode préférée :

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
}

• Créez une fonction nommée is_fibonacci_number qui prend un entier non signé et retourne un booléen.
• Itérer pour tous les nombres de 0 à notre nombre donné n inclus.
• Initialiser notre séquence Fibonacci en commençant par 0 et 1 comme les nombres previous et current respectivement.
• Itérer pendant que le nombre current est inférieur au nombre d’itération i en cours.
• Ajoutez le nombre previous et le nombre current pour obtenir le nombre next.
• Mettre à jour le nombre previous avec le nombre current.
• Mettre à jour le nombre current avec le nombre next.
• Une fois que current est supérieur ou égal au nombre donné n, nous sortirons de la boucle.
• Vérifiez si le nombre current est égal au nombre donné n et si c’est le cas retourner true.
• Sinon, retournez false.

Maintenant, nous devrons mettre à jour notre fonction 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(),
        }
    }
}

• Renommez la fonction fizz_buzz en fizz_buzz_fibonacci pour la rendre plus descriptive.
• Appelez notre fonction associée is_fibonacci_number.
• Si le résultat de is_fibonacci_number est true, alors retournez Fibonacci.
• Si le résultat de is_fibonacci_number est false, alors effectuez la même logique Fizz,Buzz, FizzBuzz, ou nombre en retournant le résultat.

Parce que nous renommons fizz_buzz en fizz_buzz_fibonacci, il nous faut également mettre à jour notre fonction play_game:

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

Les fonctions main et bench_play_game peuvent rester exactement les mêmes.

Benchmarking de FizzBuzzFibonacci

Maintenant nous pouvons relancer notre 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

En remontant notre historique de terminal, nous pouvons faire une comparaison visuelle entre les performances de nos jeux FizzBuzz et FizzBuzzFibonacci : 4,879 ns contre 22,167 ns. Vos chiffres seront un peu différents des miens. Cependant, la différence entre les deux jeux est probablement dans l’ordre de 5x. Cela me semble bon ! Surtout pour ajouter une fonctionnalité aussi fantaisiste que Fibonacci à notre jeu. Les enfants vont adorer !

Étendre FizzBuzzFibonacci en Rust

Notre jeu est un succès! Les enfants adorent jouer à FizzBuzzFibonacci. Tellement que les dirigeants veulent une suite. Mais c’est le monde moderne, nous avons besoin de revenus récurrents annuels (ARR) et non de ventes uniques! La nouvelle vision de notre jeu est qu’il est sans fin, plus besoin de vivre entre les limites de 1 et 100 (même si c’est inclusif). Non, nous partons vers de nouveaux horizons!

Les règles pour Open World FizzBuzzFibonacci sont les suivantes :

Écrivez un programme qui prend en entrée n’importe quel nombre entier positif et affiche :

• Pour les multiples de trois, affichez Fizz
• Pour les multiples de cinq, affichez Buzz
• Pour les multiples à la fois de trois et de cinq, affichez FizzBuzz
• Pour les nombres qui font partie de la séquence de Fibonacci, affichez uniquement Fibonacci
• Pour tous les autres, affichez le nombre

Pour faire fonctionner notre jeu pour n’importe quel nombre, nous devrons accepter un argument de ligne de commande. Mettez à jour la fonction main pour qu’elle ressemble à ceci :

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

• Collectez tous les arguments (args) passés à notre jeu depuis la ligne de commande.
• Obtenez le premier argument passé à notre jeu et analysez-le comme un entier non signé i.
• Si l’analyse échoue ou si aucun argument n’est transmis, par défaut, jouez à notre jeu avec 15 comme entrée.
• Enfin, jouez à notre jeu avec le nouvel entier non signé i analysé.

Maintenant, nous pouvons jouer à notre jeu avec n’importe quel nombre! Utilisez cargo run suivi de -- pour passer des arguments à notre jeu :

$ 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

Et si nous oublions de fournir un numéro ou fournissons un numéro invalide :

$ 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, c’était des tests très approfondis! CI passe. Nos patrons sont ravis. Expédions-le! 🚀

La fin

🐰 … la fin de votre carrière peut-être ?

Rien que pour rire! Tout est en feu! 🔥

Au début, tout semblait aller bien. Et puis à 02h07 du matin le samedi, mon bip a sonné :

📟 Votre jeu est en feu! 🔥

Après me être précipité hors du lit, j’ai essayé de comprendre ce qui se passait. J’ai essayé de rechercher dans les journaux, mais c’était difficile parce que tout continuait de s’effondrer. Finalement, j’ai trouvé le problème. Les enfants ! Ils adorent notre jeu tellement, qu’ils jouaient jusqu’à un million! Dans un éclair de génie, j’ai ajouté deux nouveaux points de référence :

#[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 pour jouer au jeu avec le nombre cent (100).
• Un micro-benchmark bench_play_game_1_000_000 pour jouer au jeu avec le nombre un million (1_000_000).

Lorsque je l’ai exécuté, j’ai obtenu ceci :

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

Attendez un peu… attendez un peu…

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

Quoi ! 439 ns x 1,000 devrait être 439,000 ns pas 9,586,977 ns 🤯 Même si j’ai correctement codé ma séquence de Fibonacci, je dois avoir un bug de performance quelque part.

Corriger FizzBuzzFibonacci en Rust

Jetons un autre coup d’œil à cette fonction 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
}

Maintenant que je pense à la performance, je réalise que j’ai une boucle supplémentaire inutile. Nous pouvons complètement nous débarrasser de la boucle for i in 0..=n {} et il suffit de comparer la valeur current au nombre donné (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
}

• Mettez à jour votre fonction is_fibonacci_number.
• Initialisez notre séquence de Fibonacci en commençant par 0 et 1 comme nombres previous et current respectivement.
• Itérez tant que le numéro current est inférieur au nombre donné n.
• Ajoutez le numéro previous et current pour obtenir le numéro next.
• Mettez à jour le numéro previous pour le numéro current.
• Mettez à jour le numéro current pour le numéro next.
• Une fois que current est supérieur ou égal au nombre donné n, nous sortirons de la boucle.
• Vérifiez si le numéro current est égal au nombre donné n et renvoyez ce résultat.

Maintenant, relançons ces benchmarks et voyons comment nous nous en sommes sortis :

$ 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, wow ! Notre benchmark bench_play_game est revenu à peu près au niveau où il était pour le FizzBuzz original. J’aimerais me souvenir exactement de ce score. Mais ça fait trois semaines. Mon historique de terminal ne remonte pas si loin. Mais je pense que c’est proche !

Le benchmark bench_play_game_100 est descendu près de 10 fois, de 439 ns à 46 ns. Et le benchmark bench_play_game_1_000_000 est descendu plus de 10 000 fois ! De 9,586,977 ns à 53 ns !

🐰 Hé, au moins on a attrapé ce bug de performance avant qu’il n’arrive en production… oh, attendez. Jamais d’esprit…

Détection des régressions de performances dans l’intégration continue (CI)

Les dirigeants n’étaient pas contents du torrent de critiques négatives que notre jeu a reçu à cause de mon petit bug de performance. Ils m’ont dit de ne pas laisser cela se reproduire, et quand j’ai demandé comment, ils m’ont juste dit de ne pas le refaire. Comment suis-je censé gérer cela‽

Heureusement, j’ai trouvé cet outil open source génial appelé Bencher. Il y a un niveau gratuit super généreux, donc je peux simplement utiliser Bencher Cloud pour mes projets personnels. Et au travail où tout doit être dans notre cloud privé, j’ai commencé à utiliser Bencher Self-Hosted.

Bencher a des adaptateurs intégrés, il est donc facile de l’intégrer dans CI. Après avoir suivi le guide de démarrage rapide, je suis en mesure d’exécuter mes benchmarks et de les suivre avec 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

En utilisant cet astucieux appareil de voyage dans le temps qu’un gentil lapin m’a donné, j’ai pu revenir en arrière et revivre ce qui se serait passé si nous utilisions Bencher depuis le début. Vous pouvez voir où nous avons d’abord poussé l’implémentation buggée de FizzBuzzFibonacci. J’ai immédiatement obtenu des échecs dans CI en commentaire sur ma demande de tirage. Ce même jour, j’ai corrigé le bug de performance, en supprimant cette boucle inutile et supplémentaire. Pas de feux. Juste des utilisateurs heureux.

Bencher: Benchmarking Continu

Bencher est une suite d’outils de benchmarking continu. Avez-vous déjà eu une régression de performance qui a impacté vos utilisateurs ? Bencher aurait pu empêcher cela de se produire. Bencher vous permet de détecter et de prévenir les régressions de performance avant qu’elles n’arrivent en production.

• Exécuter: Exécutez vos benchmarks localement ou en CI en utilisant vos outils de benchmarking préférés. La CLI bencher enveloppe simplement votre harnais de benchmarking existant et stocke ses résultats.
• Suivre: Suivez les résultats de vos benchmarks au fil du temps. Surveillez, interrogez et graphiquez les résultats à l’aide de la console web Bencher en fonction de la branche source, du banc d’essai et de la mesure.
• Détecter: Détectez les régressions de performances en CI. Bencher utilise des analyses de pointe et personnalisables pour détecter les régressions de performances avant qu’elles n’arrivent en production.

Pour les mêmes raisons que les tests unitaires sont exécutés en CI pour prévenir les régressions de fonctionnalités, les benchmarks devraient être exécutés en CI avec Bencher pour prévenir les régressions de performance. Les bugs de performance sont des bugs !

Commencez à détecter les régressions de performances en CI — essayez Bencher Cloud gratuitement.