Wie man Rust Code mit Criterion benchmarkt

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 unterstützt von Bencher. Aber warum sollte man sich für Criterion entscheiden? Criterion ist der de facto Standard-Benchmarking-Harness in der Rust-Community. Ich würde vorschlagen, Criterion für das Benchmarking der Latenz Ihres Codes zu verwenden. Das heißt, Criterion ist großartig für die Messung der Wanduhrzeit.

Refactoring von FizzBuzz

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. Um dies zu tun, müssen wir einige Änderungen vornehmen.

Erstelle unter src eine neue Datei namens lib.rs:

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

Füge den folgenden Code zu lib.rs hinzu:

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

pub fn fizz_buzz(n: u32) -> String {
    match (n % 3, n % 5) {
        (0, 0) => "FizzBuzz".to_string(),
        (0, _) => "Fizz".to_string(),
        (_, 0) => "Buzz".to_string(),
        (_, _) => n.to_string(),
    }
}

• play_game: Nimmt eine vorzeichenlose Ganzzahl n entgegen, ruft fizz_buzz mit dieser Zahl auf und gibt das Ergebnis aus, wenn print true ist.
• fizz_buzz: Nimmt eine vorzeichenlose Ganzzahl n entgegen und führt die tatsächliche Fizz, Buzz, FizzBuzz oder Zahlenlogik aus und gibt das Ergebnis als Zeichenkette zurück.

Aktualisiere dann main.rs, um so auszusehen:

use game::play_game;

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

• game::play_game: Importiere play_game aus der game Crate, die wir gerade mit lib.rs erstellt haben.
• main: Der Haupt-Einstiegspunkt in unser Programm, welcher durch die Zahlen 1 bis 100 inklusive iteriert und play_game für jede Zahl aufruft, wobei print auf true gesetzt ist.

Benchmarking von FizzBuzz

Um unseren Code zu benchmarken, müssen wir ein benches Verzeichnis erstellen und eine Datei hinzufügen, um unsere Benchmarks zu enthalten, play_game.rs:

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

Fügen Sie in play_game.rs den folgenden Code hinzu:

use criterion::{criterion_group, criterion_main, Criterion};

use game::play_game;

fn bench_play_game(c: &mut Criterion) {
    c.bench_function("bench_play_game", |b| {
        b.iter(|| {
            std::hint::black_box(for i in 1..=100 {
                play_game(i, false)
            });
        });
    });
}

criterion_group!(
    benches,
    bench_play_game,
);
criterion_main!(benches);

• Importieren Sie den Criterion Benchmark-Runner.
• Importieren Sie die Funktion play_game aus unserem game Crate.
• Erstellen Sie eine Funktion namens bench_play_game, die eine veränderliche Referenz auf Criterion annimmt.
• Verwenden Sie die Criterion-Instanz (c), um einen Benchmark namens bench_play_game zu erstellen.
• Verwenden Sie dann den Benchmark-Runner (b), um unseren Makro-Benchmark mehrmals auszuführen.
• Führen Sie unseren Makro-Benchmark in einer “black box” aus, damit der Compiler unseren Code nicht optimiert.
• Iterieren Sie von 1 bis 100 inklusive.
• Rufen Sie für jede Zahl play_game auf, mit print auf false gesetzt.

Jetzt müssen wir das game Crate konfigurieren, um unsere Benchmarks auszuführen.

Fügen Sie das Folgende am Ende Ihrer Cargo.toml Datei hinzu:

[dev-dependencies]
criterion = "0.5"

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

• criterion: Fügen Sie criterion als Entwicklungsabhängigkeit hinzu, da wir es nur für Performance-Tests verwenden.
• bench: Registrieren Sie play_game als Benchmark und setzen Sie harness auf false, da wir Criterion als unser Benchmarking-Harness verwenden werden.

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 4.79s
     Running unittests src/main.rs (target/release/deps/game-68f58c96f4025bd4)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running unittests src/main.rs (target/release/deps/game-043972c4132076a9)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running benches/play_game.rs (target/release/deps/play_game-e0857103eb02eb56)
bench_play_game         time:   [3.0020 µs 3.0781 µs 3.1730 µs]
Found 12 outliers among 100 measurements (12.00%)
  2 (2.00%) high mild
  10 (10.00%) high severe

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

Endlich können wir unsere müden Entwicklerköpfe zur Ruhe legen… Nur ein Scherz, unsere Nutzer wollen eine neue Funktion!

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, print: bool) {
    let result = fizz_buzz_fibonacci(n);
    if print {
        println!("{result}");
    }
}

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

Benchmarking 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 4.79s
     Running unittests src/main.rs (target/release/deps/game-68f58c96f4025bd4)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running unittests src/main.rs (target/release/deps/game-043972c4132076a9)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running benches/play_game.rs (target/release/deps/play_game-e0857103eb02eb56)
bench_play_game         time:   [20.067 µs 20.107 µs 20.149 µs]
                        change: [+557.22% +568.69% +577.93%] (p = 0.00 < 0.05)
                        Performance has regressed.
Found 6 outliers among 100 measurements (6.00%)
  4 (4.00%) high mild
  2 (2.00%) high severe

Oh, toll! Criterion sagt uns, dass der Unterschied zwischen der Performance unserer FizzBuzz- und FizzBuzzFibonacci-Spiele +568,69% beträgt. Ihre Zahlen werden etwas anders sein als meine. Jedoch ist der Unterschied zwischen den beiden Spielen wahrscheinlich in der 5x Spanne. Das scheint mir gut! Besonders für das Hinzufügen einer so schicken klingenden Funktion 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, true);
}

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

fn bench_play_game_100(c: &mut Criterion) {
    c.bench_function("bench_play_game_100", |b| {
        b.iter(|| std::hint::black_box(play_game(100, false)));
    });
}

fn bench_play_game_1_000_000(c: &mut Criterion) {
    c.bench_function("bench_play_game_1_000_000", |b| {
        b.iter(|| std::hint::black_box(play_game(1_000_000, false)));
    });
}

• Ein Mikro-Benchmark bench_play_game_100 zum Spielen des Spiels mit der Zahl einhundert (100)
• Ein Mikro-Benchmark bench_play_game_1_000_000 zum Spielen des Spiels mit der Zahl eine Million (1_000_000)

Als ich es laufen ließ, bekam ich das:

$ cargo bench
   Compiling playground v0.0.1 (/home/bencher)
    Finished bench [optimized] target(s) in 4.79s
     Running unittests src/main.rs (target/release/deps/game-68f58c96f4025bd4)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running unittests src/main.rs (target/release/deps/game-043972c4132076a9)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running benches/play_game.rs (target/release/deps/play_game-e0857103eb02eb56)
bench_play_game         time:   [20.024 µs 20.058 µs 20.096 µs]
                        change: [-0.0801% +0.1431% +0.3734%] (p = 0.21 > 0.05)
                        No change in performance detected.
Found 17 outliers among 100 measurements (17.00%)
  9 (9.00%) high mild
  8 (8.00%) high severe

bench_play_game_100     time:   [403.00 ns 403.57 ns 404.27 ns]
Found 13 outliers among 100 measurements (13.00%)
  6 (6.00%) high mild
  7 (7.00%) high severe

Warten Sie darauf… warten Sie darauf…

bench_play_game_1_000_000
                        time:   [9.5865 ms 9.5968 ms 9.6087 ms]
Found 16 outliers among 100 measurements (16.00%)
  8 (8.00%) high mild
  8 (8.00%) high severe

Was! 403.57 ns x 1,000 sollte 403,570 ns sein, nicht 9,596,800 ns (9.5968 ms x 1_000_000 ns/1 ms) 🤯 Obwohl ich meinen Fibonacci-Sequenz-Code funktional richtig bekommen habe, muss ich irgendwo einen Performance-Bug 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 ausführen und sehen, wie wir uns geschlagen haben:

$ cargo bench
   Compiling playground v0.0.1 (/home/bencher)
    Finished bench [optimized] target(s) in 4.79s
     Running unittests src/main.rs (target/release/deps/game-68f58c96f4025bd4)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running unittests src/main.rs (target/release/deps/game-043972c4132076a9)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running benches/play_game.rs (target/release/deps/play_game-e0857103eb02eb56)
bench_play_game         time:   [3.1201 µs 3.1772 µs 3.2536 µs]
                        change: [-84.469% -84.286% -84.016%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 5 outliers among 100 measurements (5.00%)
  1 (1.00%) high mild
  4 (4.00%) high severe

bench_play_game_100     time:   [24.460 ns 24.555 ns 24.650 ns]
                        change: [-93.976% -93.950% -93.927%] (p = 0.00 < 0.05)
                        Performance has improved.

bench_play_game_1_000_000
                        time:   [30.260 ns 30.403 ns 30.564 ns]
                        change: [-100.000% -100.000% -100.000%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 4 outliers among 100 measurements (4.00%)
  1 (1.00%) high mild
  3 (3.00%) high severe

Oh, wow! Unser bench_play_game Benchmark ist wieder ungefähr dort, wo er für das ursprüngliche FizzBuzz war. Ich wünschte, ich könnte mich genau an diesen Score erinnern. Es sind jedoch drei Wochen vergangen. Meine Terminalhistorie reicht nicht so weit zurück. Und Criterion vergleicht nur mit dem neuesten Ergebnis. Aber ich denke, es ist eng!

Der bench_play_game_100 Benchmark ist fast 10x herunter, -93,950%. Und der bench_play_game_1_000_000 Benchmark ist mehr als 10.000x herunter! 9,596,800 ns auf 30,403 ns! Wir haben sogar den Wechselmesser von Criterion ausgereizt, der nur bis -100,000% geht!

🐰 Hey, wenigstens haben wir diesen Performance-Bug gefangen, bevor er es in die Produktion geschafft hat… oh, richtig. Vergiss es…

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.07s
     Running unittests src/lib.rs (target/release/deps/game-13f4bad779fbfde4)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running unittests src/main.rs (target/release/deps/game-043972c4132076a9)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running benches/play_game.rs (target/release/deps/play_game-e0857103eb02eb56)
Gnuplot not found, using plotters backend
bench_play_game         time:   [3.0713 µs 3.0902 µs 3.1132 µs]
Found 16 outliers among 100 measurements (16.00%)
  3 (3.00%) high mild
  13 (13.00%) high severe

bench_play_game_100     time:   [23.938 ns 23.970 ns 24.009 ns]
Found 15 outliers among 100 measurements (15.00%)
  5 (5.00%) high mild
  10 (10.00%) high severe

bench_play_game_1_000_000
                        time:   [30.004 ns 30.127 ns 30.279 ns]
Found 5 outliers among 100 measurements (5.00%)
  1 (1.00%) high mild
  4 (4.00%) high severe

Bencher New Report:
...
View results:
- bench_play_game (Latency): https://bencher.dev/console/projects/game/perf?measures=52507e04-ffd9-4021-b141-7d4b9f1e9194&branches=3a27b3ce-225c-4076-af7c-75adbc34ef9a&testbeds=bc05ed88-74c1-430d-b96a-5394fdd18bb0&benchmarks=077449e5-5b45-4c00-bdfb-3a277413180d&start_time=1697224006000&end_time=1699816009000&upper_boundary=true
- bench_play_game_100 (Latency): https://bencher.dev/console/projects/game/perf?measures=52507e04-ffd9-4021-b141-7d4b9f1e9194&branches=3a27b3ce-225c-4076-af7c-75adbc34ef9a&testbeds=bc05ed88-74c1-430d-b96a-5394fdd18bb0&benchmarks=96508869-4fa2-44ac-8e60-b635b83a17b7&start_time=1697224006000&end_time=1699816009000&upper_boundary=true
- bench_play_game_1_000_000 (Latency): https://bencher.dev/console/projects/game/perf?measures=52507e04-ffd9-4021-b141-7d4b9f1e9194&branches=3a27b3ce-225c-4076-af7c-75adbc34ef9a&testbeds=bc05ed88-74c1-430d-b96a-5394fdd18bb0&benchmarks=ff014217-4570-42ea-8813-6ed0284500a4&start_time=1697224006000&end_time=1699816009000&upper_boundary=true

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.