Benchmark von Rust-Code mit libtest bench

Everett Pompeii

Was ist Benchmarking?

Benchmarking ist die Praxis, die Leistung Ihres Codes zu testen, um zu sehen, wie schnell (Latenz) oder wie viel (Durchsatz) Arbeit er leisten kann. Dieser oft übersehene Schritt in der Softwareentwicklung ist entscheidend für die Erstellung und Wartung von schnellem und leistungsstarkem Code. Benchmarking liefert die notwendigen Metriken für Entwickler, um zu verstehen, wie gut ihr Code unter verschiedenen Arbeitslasten und Bedingungen funktioniert. Aus den gleichen Gründen, aus denen Sie Unit- und Integrationstests schreiben, um Funktionsregressionen zu verhindern, sollten Sie Benchmarks schreiben, um Leistungsregressionen zu verhindern. Leistungsfehler sind Fehler!

Schreiben Sie FizzBuzz in Rust

Um Benchmarks zu schreiben, benötigen wir einige Quellcodes zum Benchmarken. Zum Anfang werden wir ein sehr einfaches Programm schreiben, FizzBuzz.

Die Regeln für FizzBuzz lauten wie folgt:

Schreibe ein Programm, das die ganzen Zahlen von 1 bis 100 (inklusiv) ausgibt:

• Für Vielfache von drei, drucke Fizz
• Für Vielfache von fünf, drucke Buzz
• Für Vielfache von drei und fünf, drucke FizzBuzz
• Für alle anderen, drucke die Zahl

Es gibt viele Möglichkeiten, FizzBuzz zu schreiben. Also wählen wir meine Lieblingsmethode:

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

• Erstellen Sie eine main Funktion
• Iteriere von 1 bis 100 einschließlich.
• Berechne für jede Zahl den Modulus (Rest nach der Division) sowohl für 3 als auch für 5.
• Musterabgleich auf die beiden Reste. Wenn der Rest 0 ist, dann ist die Zahl durch den gegebenen Faktor teilbar.
• Wenn der Rest für 3 und 5 beide 0 ist, dann drucke FizzBuzz.
• Wenn der Rest nur für 3 0 ist, dann drucke Fizz.
• Wenn der Rest nur für 5 0 ist, dann drucke Buzz.
• Andernfalls drucke einfach die Zahl.

Schritt für Schritt folgen

Um dieser ausführlichen Anleitung zu folgen, müssen Sie zuerst Rust installieren.

🐰 Der Quellcode für diesen Beitrag ist auf GitHub verfügbar

Nachdem Sie Rust installiert haben, können Sie ein Terminalfenster öffnen und eingeben: cargo init game

Navigieren Sie dann in das neu erstellte Verzeichnis game.

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

Sie sollten ein Verzeichnis namens src mit einer Datei namens main.rs sehen:

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

Ersetzen Sie dessen Inhalt mit der oben genannten FizzBuzz-Implementierung. Führen Sie dann cargo run aus. Die Ausgabe sollte so aussehen:

$ 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! Sie meistern das Coding-Interview!

Eine neue Datei Cargo.lock sollte erzeugt worden sein:

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

Bevor wir weitermachen, ist es wichtig, die Unterschiede zwischen Mikro-Benchmarking und Makro-Benchmarking zu besprechen.

Micro-Benchmarking vs. Macro-Benchmarking

Es gibt zwei Hauptkategorien von Software-Benchmarks: Micro-Benchmarks und Macro-Benchmarks. Micro-Benchmarks arbeiten auf einer Ebene ähnlich wie Unit-Tests. Zum Beispiel wäre ein Benchmark für eine Funktion, die Fizz, Buzz oder FizzBuzz für eine einzelne Zahl ermittelt, ein Micro-Benchmark. Macro-Benchmarks arbeiten auf einer Ebene, die Integrationstests ähnelt. Zum Beispiel wäre ein Benchmark für eine Funktion, die das gesamte Spiel von FizzBuzz spielt, von 1 bis 100, ein Macro-Benchmark.

Im Allgemeinen ist es am besten, auf der niedrigstmöglichen Abstraktionsebene zu testen. Im Falle von Benchmarks macht dies sie sowohl leichter zu pflegen, und es hilft, die Menge an Rauschen in den Messungen zu reduzieren. Allerdings können genau wie End-to-End-Tests, die für eine Überprüfung der gesamten Systemzusammenstellung sehr hilfreich sein können, Macro-Benchmarks sehr nützlich sein, um sicherzustellen, dass die kritischen Pfade durch Ihre Software performant bleiben.

Benchmarking in Rust

Die drei beliebten Optionen für Benchmarking in Rust sind: libtest bench, Criterion, und Iai.

libtest ist Rusts eingebaute Einheitentest- und Benchmarking-Bibliothek. Obwohl es Teil der Rust-Standardbibliothek ist, wird libtest bench immer noch als instabil betrachtet, weshalb es nur in den nightly Compiler-Releases verfügbar ist. Um mit dem stabilen Rust-Compiler zu arbeiten, muss ein separates Benchmarking-Harness verwendet werden. Keines von beiden wird jedoch aktiv weiterentwickelt.

Das beliebteste Benchmarking-Harness innerhalb des Rust-Ökosystems ist Criterion. Es funktioniert sowohl mit stabilen als auch mit nightly Rust-Compiler-Releases und ist zum De-facto-Standard innerhalb der Rust-Community geworden. Criterion ist auch viel funktionsreicher im Vergleich zum libtest bench.

Eine experimentelle Alternative zu Criterion ist Iai, vom selben Ersteller wie Criterion. Es verwendet jedoch Befehlszählungen anstelle der Echtzeitmessung: CPU-Befehle, L1-Zugriffe, L2-Zugriffe und RAM-Zugriffe. Dies ermöglicht einmalige Benchmarks, da diese Metriken zwischen den Durchläufen nahezu identisch bleiben sollten.

Alle drei werden von Bencher unterstützt. Warum also libtest bench wählen? Es könnte eine gute Idee sein, wenn Sie versuchen, die externen Abhängigkeiten Ihres Projekts zu begrenzen und Ihr Projekt verwendet bereits die Nightly-Toolchain. Abgesehen davon würde ich entweder Criterion oder Iai je nach Anwendungsfall empfehlen.

Installation von Rust nightly

All das gesagt, wir werden libtest bench verwenden, also stellen wir unsere Rust-Toolchain auf nightly. Erstellen Sie eine Datei rust-toolchain.toml im Wurzelverzeichnis Ihres game-Projekts, neben Cargo.toml.

[toolchain]
channel = "nightly"

Ihre Verzeichnisstruktur sollte jetzt so aussehen:

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

Wenn das erledigt ist, führen Sie cargo run erneut aus. Es sollte eine Minute dauern, bis die neue, nächtliche Toolchain installiert ist, bevor sie erneut ausgeführt wird und Ihnen die gleiche Ausgabe wie zuvor liefert.

FizzBuzz neu strukturieren

Um unsere FizzBuzz-Anwendung zu testen, müssen wir unsere Logik von der main Funktion des Programms entkoppeln. Benchmark-Harnesses können die main Funktion nicht benchmarken.

Aktualisieren Sie Ihren Code, sodass er nun so aussieht:

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

Wir haben nun unseren Code in drei verschiedene Funktionen aufgeteilt:

• main: Der Haupt-Einstiegspunkt in unser Programm, der die Zahlen 1 bis 100 inklusive durchläuft und für jede Zahl play_game aufruft.
• play_game: Nimmt eine vorzeichenlose Ganzzahl n entgegen, ruft fizz_buzz mit dieser Zahl auf, und gibt das Ergebnis aus.
• fizz_buzz: Nimmt eine vorzeichenlose Ganzzahl n entgegen und führt die tatsächliche Fizz, Buzz, FizzBuzz oder Numerik-Logik aus, die das Ergebnis als Zeichenkette zurückgibt.

Benchmarking FizzBuzz

Um die instabile libtest crate zu verwenden, müssen wir das test-Feature für unseren Code aktivieren und die test crate importieren. Fügen Sie das oben auf main.rs ein:

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

Jetzt sind wir bereit, unseren ersten Benchmak hinzuzufügen! Fügen Sie das ganz unten auf main.rs ein:

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

• Erstellen Sie ein Modul mit dem Namen benchmarks und stellen Sie die Compiler-Konfiguration auf den test Modus.
• Importieren Sie den Benchmark-Runner Bencher. (🐰 Cooler Name!)
• Importieren Sie unsere Funktion play_game.
• Erstellen Sie einen Benchmark namens bench_play_game, der eine veränderbare Referenz auf Bencher erhält.
• Stellen Sie das #[bench] Attribut ein, um anzugeben, dass bench_play_game ein Benchmark ist.
• Nutzen Sie die Bencher-Instanz (b), um unseren Makro-Benchmark mehrmals auszuführen.
• Führen Sie unseren Makro-Benchmark innerhalb einer “Black Box” aus, damit der Compiler unseren Code nicht optimiert.
• Iterieren Sie von 1 bis 100 einschließlich.
• Rufen Sie für jede Zahl play_game auf.

Jetzt sind wir bereit, unseren Code zu benchmarken, führen Sie cargo bench aus:

$ 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

🐰 Lassen Sie uns die Rübe drehen! Wir haben unsere ersten Benchmark-Metriken!

Endlich können wir unsere müden Entwicklerköpfe ausruhen… Nur ein Scherz, unsere Benutzer wollen ein neues Feature!

Schreiben Sie FizzBuzzFibonacci in Rust

Unsere Key Performance Indicators (KPIs) sind runter, daher möchte unser Produkt Manager (PM), dass wir ein neues Feature hinzufügen. Nach viel Brainstorming und vielen Nutzerinterviews wurde entschieden, dass das gute alte FizzBuzz nicht ausreicht. Die Kids heutzutage wollen ein neues Spiel, FizzBuzzFibonacci.

Die Regeln für FizzBuzzFibonacci lauten wie folgt:

Schreibe ein Programm, welches die Zahlen von 1 bis 100 (inklusiv) ausgibt:

• Für Vielfache von drei, drucke Fizz
• Für Vielfache von fünf, drucke Buzz
• Für Vielfache von sowohl drei als auch fünf, drucke FizzBuzz
• Für Zahlen, die Teil der Fibonacci-Sequenz sind, drucke nur Fibonacci
• Für alle anderen, drucke die Zahl

Die Fibonacci-Sequenz ist eine Sequenz, bei der jede Zahl die Summe der beiden vorhergehenden Zahlen ist. Zum Beispiel wäre, beginnend bei 0 und 1, die nächste Zahl in der Fibonacci-Sequenz 1. Gefolgt von: 2, 3, 5, 8 und so weiter. Zahlen, die Teil der Fibonacci-Sequenz sind, werden als Fibonacci-Zahlen bezeichnet. Daher müssen wir eine Funktion schreiben, die Fibonacci-Zahlen erkennt.

Es gibt viele Arten, die Fibonacci-Sequenz zu schreiben und ebenso viele Möglichkeiten, eine Fibonacci-Zahl zu erkennen. Daher werden wir meine Lieblingsmethode wählen:

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
}

• Erstellen Sie eine Funktion namens is_fibonacci_number die eine nicht signierte ganze Zahl nimmt und einen boolschen Wert zurückgibt.
• Iterieren Sie über alle Zahlen von 0 bis zur gegebenen Zahl n einschließlich.
• Initialisieren Sie unsere Fibonacci-Sequenz mit 0 und 1 als den previous- und current-Zahlen.
• Iterieren Sie solange die current Zahl kleiner ist als die aktuelle Iteration i.
• Addieren Sie die previous und current Zahlen, um die next Zahl zu bekommen.
• Aktualisieren Sie die previous Zahl auf die current Zahl.
• Aktualisieren Sie die current Zahl auf die next Zahl.
• Sobald current größer oder gleich der gegebenen Zahl n ist, beenden wir die Schleife.
• Überprüfen Sie, ob die current Zahl gleich der gegebenen Zahl n ist und geben Sie in diesem Fall true zurück.
• Andernfalls, geben Sie false zurück.

Nun müssen wir unsere fizz_buzz Funktion aktualisieren:

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

• Benennen Sie die fizz_buzz Funktion in fizz_buzz_fibonacci um, um sie aussagekräftiger zu machen.
• Rufen Sie unsere Hilfsfunktion is_fibonacci_number auf.
• Wenn das Ergebnis von is_fibonacci_number true ist, dann geben Sie Fibonacci zurück.
• Wenn das Ergebnis von is_fibonacci_number false ist, dann führen Sie die gleiche Fizz, Buzz, FizzBuzz, oder Zahl Logik aus und geben Sie das Ergebnis zurück.

Da wir fizz_buzz in fizz_buzz_fibonacci umbenannt haben, müssen wir auch unsere play_game Funktion aktualisieren:

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

Unsere Funktionen main und bench_play_game können genau gleich bleiben.

Benchmark von FizzBuzzFibonacci

Jetzt können wir unseren Benchmark erneut ausführen:

$ 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

Wenn wir in unserer Terminal-Historie zurückscrollen, können wir einen Augenvergleich zwischen der Leistung unseres FizzBuzz und FizzBuzzFibonacci-Spiels machen: 4.879 ns vs 22.167 ns. Ihre Zahlen werden etwas von meinen abweichen. Jedoch ist der Unterschied zwischen den beiden Spielen wahrscheinlich im Bereich von 5x. Das scheint mir gut zu sein! Besonders für das Hinzufügen eines so schick klingenden Features wie Fibonacci zu unserem Spiel. Den Kindern wird es gefallen!

Erweiterung von FizzBuzzFibonacci in Rust

Unser Spiel ist ein Hit! Die Kinder lieben es wirklich, FizzBuzzFibonacci zu spielen. So sehr, dass von den Geschäftsführern die Nachricht kam, dass sie eine Fortsetzung wollen. Aber das ist die moderne Welt, wir brauchen jährlich wiederkehrende Einnahmen (ARR) anstatt einmaliger Käufe! Die neue Vision für unser Spiel ist, dass es offen endet, kein Leben mehr zwischen der Begrenzung von 1 und 100 (auch wenn es inklusive ist). Nein, wir sind auf zu neuen Fronten!

Die Regeln für Open World FizzBuzzFibonacci lauten wie folgt:

Schreiben Sie ein Programm, das jede positive ganze Zahl akzeptiert und ausgibt:

• Für Vielfache von drei, drucken Sie Fizz
• Für Vielfache von fünf, drucken Sie Buzz
• Für Vielfache von drei und fünf, drucken Sie FizzBuzz
• Für Zahlen, die Teil der Fibonacci-Sequenz sind, drucken Sie nur Fibonacci
• Für alle anderen drucken Sie die Zahl

Um unser Spiel für jede Zahl funktionieren zu lassen, werden wir ein Kommandozeilenargument akzeptieren müssen. Aktualisieren Sie die main Funktion, um so auszusehen:

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

• Sammeln Sie alle Argumente (args), die unserer Spiel von der Kommandozeile aus übergeben werden.
• Nehmen Sie das erste Argument, das zu unserem Spiel übergeben wird, und analysieren Sie es als eine vorzeichenlose Ganzzahl i.
• Wenn das Parsen fehlschlägt oder kein Argument übergeben wird, fahren Sie standardmäßig mit unserem Spiel mit 15 als Eingang fort.
• Spielen Sie schließlich unser Spiel mit der neu analysierten vorzeichenlosen Ganzzahl i.

Jetzt können wir unser Spiel mit jeder Zahl spielen! Verwenden Sie cargo run gefolgt von -- um Argumente an unser Spiel zu übergeben:

$ 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

Und wenn wir eine Zahl weglassen oder eine ungültige Zahl angeben:

$ 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, das war ein gründlicher Test! CI besteht. Unsere Chefs sind begeistert. Lasst uns es ausliefern! 🚀

Das Ende

🐰 … das Ende Ihrer Karriere vielleicht?

Nur ein Scherz! Alles steht in Flammen! 🔥

Nun, anfangs schien alles gut zu laufen. Und dann um 02:07 Uhr am Samstag löste mein Pager aus:

📟 Dein Spiel steht in Flammen! 🔥

Nachdem ich aus dem Bett gehetzt war, versuchte ich herauszufinden, was los war. Ich versuchte, die Logs durchzusuchen, aber das war schwierig, weil alles ständig abstürzte. Schließlich fand ich das Problem. Die Kinder! Sie liebten unser Spiel so sehr, dass sie es bis zu einer Million hochspielten! In einem Geistesblitz fügte ich zwei neue Benchmarks hinzu:

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

• Ein Mikro-Benchmark bench_play_game_100 für das Spielen des Spiels mit der Zahl hundert (100)
• Ein Mikro-Benchmark bench_play_game_1_000_000 für das Spielen des Spiels mit der Zahl eine Million (1_000_000)

Als ich es ausgeführt habe, habe ich das bekommen:

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

Warten Sie darauf… warten Sie darauf…

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

Was! 439 ns x 1.000 sollte 439.000 ns und nicht 9.586.977 ns sein 🤯 Obwohl ich meinen Fibonacci-Sequenzcode funktional richtig bekommen habe, muss ich irgendwo einen Leistungsfehler haben.

FizzBuzzFibonacci in Rust korrigieren

Lassen Sie uns noch einmal einen Blick auf diese is_fibonacci_number Funktion werfen:

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
}

Jetzt, wo ich über die Leistung nachdenke, realisiere ich, dass ich eine unnötige, zusätzliche Schleife habe. Wir können die for i in 0..=n {} Schleife komplett loswerden und vergleicht einfach den current Wert mit der gegebenen Zahl (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
}

• Aktualisieren Sie Ihre is_fibonacci_number Funktion.
• Initialisieren Sie unsere Fibonacci-Sequenz, die mit 0 und 1 als previous und current Zahlen beginnt.
• Iterieren Sie, solange die current Zahl kleiner ist als die gegebene Zahl n.
• Addieren Sie die previous und current Zahl, um die next Zahl zu erhalten.
• Aktualisieren Sie die previous Zahl zur current Zahl.
• Aktualisieren Sie die current Zahl zur next Zahl.
• Sobald current größer oder gleich der gegebenen Zahl n ist, werden wir die Schleife verlassen.
• Überprüfen Sie, ob die current Zahl gleich der gegebenen Zahl n ist und geben Sie dieses Ergebnis zurück.

Jetzt lassen Sie uns diese Benchmarks erneut durchführen und sehen, wie wir abgeschnitten haben:

$ 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! Unsere bench_play_game-Benchmark ist wieder auf etwa demselben Niveau wie die ursprüngliche FizzBuzz. Ich wünschte, ich könnte mich genau an diese Punktzahl erinnern. Es sind aber schon drei Wochen vergangen. Die Historie meines Terminals geht nicht so weit zurück. Aber ich denke, es ist eng!

Die bench_play_game_100-Benchmark ist fast 10x abgesunken, von 439 ns auf 46 ns. Und das bench_play_game_1_000_000-Benchmark ist um mehr als 10.000x gesunken! Von 9.586.977 ns auf 53 ns!

🐰 Hey, wenigstens haben wir diesen Performance-Bug erkannt, bevor er in die Produktion gelangt ist… ach, stimmt. Nein…

Leistungsverschlechterungen in CI auffangen

Die Geschäftsführung war nicht glücklich über die Flut von negativen Bewertungen, die unser Spiel aufgrund meines kleinen Performance-Bugs erhalten hat. Sie sagten mir, dass so etwas nicht wieder passieren darf, und als ich fragte wie, sagten sie mir einfach, dass ich es einfach nicht noch einmal tun soll. Wie soll ich das schaffen‽

Zum Glück habe ich dieses großartige Open-Source-Tool namens Bencher gefunden. Es gibt einen sehr großzügigen kostenlosen Tier, sodass ich Bencher Cloud einfach für meine persönlichen Projekte verwenden kann. Und bei der Arbeit, wo alles in unserer privaten Cloud sein muss, habe ich angefangen, Bencher Self-Hosted zu verwenden.

Bencher hat eingebaute Adapter, also ist es einfach, es in CI zu integrieren. Nachdem ich der Quick Start Anleitung gefolgt bin, kann ich meine Benchmarks ausführen und mit Bencher verfolgen.

$ 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

Mit diesem praktischen Zeitreise-Gerät, das mir ein netter Hase gegeben hat, konnte ich zurück in die Vergangenheit reisen und nachspielen, was passiert wäre, wenn wir von Anfang an Bencher verwendet hätten. Sie können sehen, wo wir die fehlerhafte FizzBuzzFibonacci Implementierung zum ersten Mal gepusht haben. Ich habe sofort Fehler in CI als Kommentar zu meinem Pull Request bekommen. Noch am gleichen Tag habe ich den Performance-Fehler behoben, indem ich diese unnötige, zusätzliche Schleife entfernt habe. Keine Brände. Nur zufriedene Benutzer.

Bencher: Kontinuierliches Benchmarking

Bencher ist eine Suite von kontinuierlichen Benchmarking-Tools. Hatten Sie jemals eine Performance Regression, die Ihre Nutzer beeinflusste? Bencher hätte das verhindern können. Bencher ermöglicht es Ihnen, Leistungsregressionen vorher zu erkennen und zu verhindern, bevor sie in die Produktion gelangen.

• Ausführen: Führen Sie Ihre Benchmarks lokal oder in CI mit Ihren bevorzugten Benchmarking-Tools aus. Das bencher CLI umfasst einfach Ihr vorhandenes Benchmark-Harness und speichert die Ergebnisse.
• Verfolgen: Verfolgen Sie die Ergebnisse Ihrer Benchmarks im Laufe der Zeit. Überwachen, abfragen und grafisch darstellen der Ergebnisse mit der Bencher Web Konsole auf Basis des Quellzweigs, Testbetts und Maßnahme.
• Auffangen: Fangen Sie Leistungsregressionen in CI ab. Bencher verwendet modernste, anpassbare Analysen, um Leistungsregressionen zu erkennen, bevor sie in die Produktion gelangen.

Aus denselben Gründen, warum Unit Tests in CI laufen, um Feature Regressionen zu verhindern, sollten Benchmarks in CI mit Bencher ausgeführt werden, um Leistungsregressionen zu verhindern. Performance-Bugs sind Fehler!

Beginnen Sie damit, Leistungsregressionen in CI aufzufangen - probieren Sie Bencher Cloud kostenlos aus.