Flame Graphs with cargo-flamegraph

23 min read

A flame graph turns thousands of stack samples into a single picture that answers one question fast: where is my program actually spending its time? cargo-flamegraph makes producing one a single command, and learning to read it is the most leverage you can get for the least effort when optimizing Rust.

Quick Overview

A flame graph is a visualization of sampled call stacks. A profiler interrupts your program many times per second, records the call stack each time, and cargo-flamegraph aggregates those samples into stacked, colored bars: each box is a function, its width is the share of samples that function (and everything it called) was on the stack, and boxes stack vertically to show caller → callee. The wider a box, the more time the program spent there — so you scan for the widest boxes near the top to find your hot path.

For a TypeScript/JavaScript developer this is the same idea as the flame chart in Chrome DevTools’ Performance panel or the output of the 0x tool over a Node process. The mental model transfers directly. What changes in Rust is the workflow (one Cargo subcommand instead of DevTools), and the fact that you are profiling native machine code — there is no garbage collector, no JIT warm-up, and no event-loop layer between you and the CPU, so the stacks you see map cleanly onto the functions you wrote.

Note: This page is about reading and drilling into flame graphs. For choosing a profiler (samply, perf, Instruments) and setting up release builds with debug symbols, see profiling.md. For turning a hot path into a precise before/after measurement, see benchmarking.md. For the actual fixes once you have found the hot spot, see optimization.md.

TypeScript/JavaScript Example

In Node you reach for a sampling profiler when something is slow and you do not yet know why. Node ships one in the box — the V8 sampling profiler behind --prof — and the 0x package renders its output as an interactive flame graph in your browser.

Here is a small CPU-bound script: it counts word frequencies across a synthetic corpus. The normalize function is doing more work than it looks like.

1
// wordstats.ts — count word frequencies across many documents.
2
function normalize(word: string): string {
3
  // Strip non-alphanumeric characters, then lowercase.
4
  return word
5
    .split("")
6
    .filter((c) => /[a-z0-9]/i.test(c))
7
    .join("")
8
    .toLowerCase();
9
}
10

11
function wordCounts(docs: string[]): Map<string, number> {
12
  const counts = new Map<string, number>();
13
  for (const doc of docs) {
14
    for (const raw of doc.split(/\s+/)) {
15
      const word = normalize(raw);
16
      if (word.length === 0) continue;
17
      counts.set(word, (counts.get(word) ?? 0) + 1);
18
    }
19
  }
20
  return counts;
21
}
22

23
function makeCorpus(nDocs: number, wordsPerDoc: number): string[] {
24
  const vocab = ["the", "quick", "brown", "fox", "jumps", "over",
25
    "lazy", "dog", "rust", "typescript", "performance", "flamegraph", "profiler"];
26
  const docs: string[] = [];
27
  for (let d = 0; d < nDocs; d++) {
28
    const parts: string[] = [];
29
    for (let w = 0; w < wordsPerDoc; w++) {
30
      parts.push(vocab[(d * 31 + w * 7) % vocab.length]);
31
    }
32
    docs.push(parts.join(" "));
33
  }
34
  return docs;
35
}
36

37
const docs = makeCorpus(50_000, 200);
38
const counts = wordCounts(docs);
39
console.log(`distinct words: ${counts.size}`);

To profile it, you produce a V8 log and turn it into a flame graph:

1
# Built into Node — no install required. Produces an isolate-*.log file.
2
node --prof wordstats.js
3
node --prof-process isolate-*.log > processed.txt   # human-readable summary
4

5
# Or, for an interactive browser flame graph:
6
npx 0x wordstats.js                                  # opens flamegraph.html

You then open the flame graph and look for the widest tower. You would discover that normalize — and inside it the per-character regex test and the array split/join — dominates. That is the insight a flame graph gives you: not a number, but a shape that points at the guilty function.

Rust Equivalent

The same program in idiomatic Rust, with the same deliberately-wasteful normalize:

1
use std::collections::HashMap;
2

3
/// Normalize a word: keep only alphanumeric characters, then lowercase.
4
/// (Deliberately allocation-heavy so it shows up clearly in a flame graph.)
5
fn normalize(word: &str) -> String {
6
    word.chars()
7
        .filter(|c| c.is_alphanumeric())
8
        .collect::<String>()
9
        .to_lowercase()
10
}
11

12
/// Count how many times each word appears across all documents.
13
fn word_counts(docs: &[String]) -> HashMap<String, u64> {
14
    let mut counts = HashMap::new();
15
    for doc in docs {
16
        for raw in doc.split_whitespace() {
17
            let word = normalize(raw);
18
            if word.is_empty() {
19
                continue;
20
            }
21
            *counts.entry(word).or_insert(0) += 1;
22
        }
23
    }
24
    counts
25
}
26

27
/// Build a corpus of synthetic documents so the program does real work.
28
fn make_corpus(n_docs: usize, words_per_doc: usize) -> Vec<String> {
29
    let vocab = [
30
        "the", "quick", "brown", "fox", "jumps", "over", "lazy", "dog",
31
        "rust", "typescript", "performance", "flamegraph", "profiler",
32
    ];
33
    let mut docs = Vec::with_capacity(n_docs);
34
    for d in 0..n_docs {
35
        let mut doc = String::new();
36
        for w in 0..words_per_doc {
37
            doc.push_str(vocab[(d * 31 + w * 7) % vocab.len()]);
38
            doc.push(' ');
39
        }
40
        docs.push(doc);
41
    }
42
    docs
43
}
44

45
fn main() {
46
    let docs = make_corpus(50_000, 200);
47
    let counts = word_counts(&docs);
48

49
    let mut pairs: Vec<(&String, &u64)> = counts.iter().collect();
50
    pairs.sort_by(|a, b| b.1.cmp(a.1));
51

52
    println!("distinct words: {}", counts.len());
53
    for (word, count) in pairs.iter().take(3) {
54
        println!("{word}: {count}");
55
    }
56
}

Running it confirms it does real work:

1
distinct words: 13
2
the: 769232
3
dog: 769232
4
over: 769231

Now produce a flame graph. First install the tool (it is a normal crate; the current version is flamegraph 0.6.12):

1
cargo install flamegraph

Note: cargo install flamegraph gives you the cargo flamegraph subcommand. The toolchain is Rust 1.96.0 on the latest stable edition (2024); cargo new selects that edition automatically. On Linux cargo-flamegraph drives perf; on macOS it drives dtrace (which ships with the OS, but the profiler needs elevated privileges, so you run it under sudo). See profiling.md for the platform setup.

You want optimized code with debug symbols so function names survive. The cleanest way is to keep symbols in release builds. Add this to Cargo.toml:

1
# Cargo.toml — keep line-table debuginfo in release so flame graph frames are named.
2
[profile.release]
3
debug = true

Then generate the graph:

1
# Build in release, profile the run, write an interactive flamegraph.svg.
2
cargo flamegraph --bin textstats
3

4
# On macOS, dtrace needs privileges:
5
sudo cargo flamegraph --bin textstats
6

7
# Open it (it is a self-contained SVG — clickable and searchable in a browser):
8
open flamegraph.svg      # macOS;  use `xdg-open` on Linux

cargo-flamegraph builds the binary in release, runs it under the system profiler, collapses the samples, and writes a flamegraph.svg in the current directory. Open that SVG in a browser — it is interactive: click any box to zoom into that subtree, click the “Reset Zoom” text to go back, and use “Search” (top-right) to highlight every frame matching a pattern.

Detailed Explanation

What the picture means, axis by axis

The x-axis is NOT time. It is the fraction of collected samples. Boxes are sorted alphabetically within a level, not chronologically. A box that is 40% of the width means the function was on the stack in ~40% of samples — i.e. the program spent ~40% of its CPU time at or below that frame. You cannot read “this happened, then that happened” left-to-right; a flame graph is a statistical summary, not a timeline. (Chrome DevTools’ “flame chart” is time-ordered; cargo-flamegraph’s “flame graph” is aggregated. Same flames, different x-axis — this trips up DevTools veterans.)
The y-axis is stack depth. The bottom is the entry point (main, often wrapped in runtime startup frames); each box above sits on its caller. A tall narrow spire is deep recursion or a long call chain that is not itself expensive. A short wide plateau is where the work happens.
Width = self + children. A wide box does not mean that function is slow — it means that function plus everything it called is where the time went. To find the function that is itself expensive (its own instructions, not its callees), look for a box that is wide but has little or nothing stacked on top of it. That flat “ceiling” is self time.
Color is usually meaningless. The default palette is random warm hues purely so adjacent boxes are distinguishable. Do not read significance into red vs. orange.

Reading our example

In our flame graph the bottom is main, with word_counts taking nearly the entire width above it (make_corpus runs once and is comparatively thin). Stacked on word_counts you would see a wide normalize tower, and on top of that, frames for core::str::...to_lowercase, the iterator/filter chain, and — crucially — alloc/__rust_alloc and String growth frames. Those allocation frames near the top are the smoking gun: normalize allocates a fresh String for the collect, then to_lowercase allocates another String, for every word in every document (10 million words here). The flame graph shows allocation as a real, measurable plateau rather than something you have to guess at.

From picture to fix

Once the graph fingers normalize, the fix is to stop allocating per word. Lowercase the characters as you filter, and reuse one scratch buffer across the whole loop instead of returning a new String each call:

1
// src/bin/opt.rs — optimized: one reusable buffer, no per-word allocation.
2
use std::collections::HashMap;
3

4
/// Normalize into a caller-owned buffer: lowercase while filtering, no temp String.
5
fn normalize_into(word: &str, buf: &mut String) {
6
    buf.clear();
7
    for c in word.chars().filter(|c| c.is_alphanumeric()) {
8
        buf.extend(c.to_lowercase()); // to_lowercase yields chars; extend appends them
9
    }
10
}
11

12
fn word_counts(docs: &[String]) -> HashMap<String, u64> {
13
    let mut counts = HashMap::new();
14
    let mut buf = String::new(); // allocated ONCE, reused for every word
15
    for doc in docs {
16
        for raw in doc.split_whitespace() {
17
            normalize_into(raw, &mut buf);
18
            if buf.is_empty() {
19
                continue;
20
            }
21
            // Only allocate a new key String on the FIRST sight of a word.
22
            if let Some(n) = counts.get_mut(buf.as_str()) {
23
                *n += 1;
24
            } else {
25
                counts.insert(buf.clone(), 1u64);
26
            }
27
        }
28
    }
29
    counts
30
}
31

32
fn make_corpus(n_docs: usize, words_per_doc: usize) -> Vec<String> {
33
    let vocab = [
34
        "the", "quick", "brown", "fox", "jumps", "over", "lazy", "dog",
35
        "rust", "typescript", "performance", "flamegraph", "profiler",
36
    ];
37
    let mut docs = Vec::with_capacity(n_docs);
38
    for d in 0..n_docs {
39
        let mut doc = String::new();
40
        for w in 0..words_per_doc {
41
            doc.push_str(vocab[(d * 31 + w * 7) % vocab.len()]);
42
            doc.push(' ');
43
        }
44
        docs.push(doc);
45
    }
46
    docs
47
}
48

49
fn main() {
50
    let docs = make_corpus(50_000, 200);
51
    let counts = word_counts(&docs);
52
    println!("distinct words: {}", counts.len());
53
}

This keeps the same output (distinct words: 13). The honest measurement on this machine (best of five runs, user CPU time) went from about 0.82 s to 0.75 s — a real but modest win, because the corpus has only 13 distinct words so the get_mut fast path already avoids most key allocations. A flame graph of the optimized binary shows the normalize_into plateau shrink and the __rust_alloc frames atop it nearly vanish. That visual confirmation — the box you targeted got narrower — is exactly what you want from a profiler-guided change, and it is why you re-profile after every fix.

Tip: A flame graph tells you where time goes; it does not give you a trustworthy number for a small change. Confirm the actual speedup with a microbenchmark — see benchmarking.md and its black_box discussion so the optimizer does not delete the work you are measuring.

Key Differences

Concept	Chrome DevTools / `0x` (Node)	cargo-flamegraph (Rust)
What you profile	JS bundle through V8 + JIT + event loop	Native machine code, no GC/JIT layer
How to capture	DevTools “Record”; `node --prof`; `npx 0x app.js`	`cargo flamegraph --bin app`
Backend sampler	V8 sampling profiler	`perf` (Linux) / `dtrace` (macOS) / DTrace-likes
x-axis	DevTools flame chart is time-ordered; `0x` is aggregated	Aggregated samples (NOT time)
Symbol quality	Function names from source maps; inlined/JIT frames can be fuzzy	Real symbols if `debug = true`; inlining can merge frames
GC noise	Garbage-collection stacks show up as their own towers	No GC; allocation shows as `malloc`/`__rust_alloc` frames
Build step	None (interpreted/JIT)	Must build release + debuginfo or names are stripped

The deepest difference is what the wide boxes mean. In Node, a fat tower might be V8’s garbage collector reclaiming objects you allocated — work you cannot see in your own source. In Rust there is no GC, so a fat allocation tower (__rust_alloc, realloc, String/Vec growth) points at your clone(), collect(), or format! calls directly. The flame graph attributes the cost to the exact line you wrote, which makes the fix far more obvious.

Note: Unlike a DevTools recording, a cargo-flamegraph graph has no zoom-to-time-range and no “bottom-up” table by default — it is one static (but clickable) SVG. If you want an aggregated bottom-up “which function has the most self time” table, a profiler like samply gives you that view alongside the flame graph.

Common Pitfalls

1. Profiling a debug build (or release without symbols)

If you run cargo flamegraph on a default debug build, the numbers are meaningless: debug code is 10–100× slower than release and the bottleneck shifts to things that vanish under optimization. Conversely, a default release build strips debug info, so every box reads as a bare address or [unknown] and the graph is unreadable. The correct combination is optimized code with line-table debug info, which is why you add [profile.release] debug = true to Cargo.toml. cargo flamegraph builds release by default; the debug = true line is what keeps the names.

2. Reading the x-axis as a timeline

The boxes are sorted alphabetically, not by when they ran. A function that appears “to the left” did not run “first.” If you need ordering — “the slow request comes after the cache miss” — a flame graph is the wrong tool; reach for a tracing/timeline view instead. Treat the flame graph purely as “where does the aggregate time live?“

3. Blaming a wide box for time its children spent

A wide word_counts box does not mean word_counts’s own code is slow — almost all of that width is normalize underneath it. The function whose own instructions are hot is the one with a flat top (little stacked above it). Always drill up the tower to find the real self-time plateau before you start editing code.

4. Inlining makes your hot function disappear

The release optimizer inlines small functions into their callers, so the frame you expected to see (normalize) can be fused into word_counts and never appear as its own box. If a function you suspect is missing from the graph, mark it #[inline(never)] temporarily so it shows up as a distinct frame:

1
// Force a distinct frame so the profiler attributes time to THIS function,
2
// instead of inlining it into its caller. Remove once you are done profiling.
3
#[inline(never)]
4
fn normalize(word: &str) -> String {
5
    word.chars()
6
        .filter(|c| c.is_alphanumeric())
7
        .collect::<String>()
8
        .to_lowercase()
9
}
10

11
fn main() {
12
    for w in ["Rust!", "FLAMEGRAPH", "  fox,"] {
13
        println!("{w} -> {}", normalize(w));
14
    }
15
}

1
Rust! -> rust
2
FLAMEGRAPH -> flamegraph
3
  fox, -> fox

This is a diagnostic aid, not an optimization — #[inline(never)] usually makes code slower, so delete it once you have your picture.

5. The program finishes too fast to sample

A sampler that fires ~1000 times/second collects almost nothing from a 5 ms program, and the graph is pure noise. Make the workload long enough to gather thousands of samples — loop the operation, feed a bigger input (as our 50,000-document corpus does), or profile a representative workload rather than a toy. On macOS you also need to run under sudo because dtrace requires elevated privileges; forgetting that yields an empty or permission-denied graph rather than a real one.

Best Practices

Measure before you touch code. Generate a flame graph first and let the widest box pick the target. Optimizing a box that is 2% of the width can never beat optimizing the one that is 50%. (See when-to-optimize.md.)
Always release + debug = true. Keep a [profile.release] debug = true (or a dedicated profiling profile) so any release binary is ready to flame-graph without a rebuild dance.
Profile a realistic workload. Feed production-like input sizes. A flame graph of a 10-element input lies about what matters at 10 million.
Drill into self time. Find the flat ceilings (wide box, little on top) — those are the functions whose own code is hot and where edits pay off.
Use Search to total a pattern. In the SVG, search for alloc (or clone, memcpy, Drop) to highlight every matching frame and read the combined percentage at the bottom-right. This is how you quantify “how much am I spending on allocation/cloning?” across the whole program at once.
Re-profile after each change and confirm the targeted box shrank. Pair the graph with a criterion benchmark for a trustworthy number.
One change at a time. If you fix three things and re-profile, you cannot attribute the win. Flame-graph-driven optimization is a loop: graph → one hypothesis → one fix → graph again.

Real-World Example

A common production hot spot is a request handler that serializes a large response. Here a service builds a JSON report from rows; a naive version re-formats and re-allocates per row, and a flame graph immediately shows the format!/allocation tower. This is a self-contained program you can flame-graph end to end.

1
// src/main.rs — build a CSV-style report from many records.
2
// Run: cargo flamegraph --bin report   (with [profile.release] debug = true)
3

4
/// A row of telemetry, as a service might pull from a database.
5
struct Record {
6
    id: u64,
7
    region: String,
8
    latency_ms: f64,
9
    ok: bool,
10
}
11

12
fn make_records(n: usize) -> Vec<Record> {
13
    let regions = ["us-east", "us-west", "eu-central", "ap-south"];
14
    (0..n)
15
        .map(|i| Record {
16
            id: i as u64,
17
            region: regions[i % regions.len()].to_string(),
18
            latency_ms: (i % 250) as f64 + 0.5,
19
            ok: i % 17 != 0,
20
        })
21
        .collect()
22
}
23

24
/// Naive: a fresh String per row plus `format!` allocations everywhere.
25
/// In a flame graph this is a wide tower of `__rust_alloc` / `format!`.
26
fn render_naive(records: &[Record]) -> String {
27
    let mut out = String::new();
28
    for r in records {
29
        let line = format!(
30
            "{},{},{:.1},{}\n",
31
            r.id,
32
            r.region,
33
            r.latency_ms,
34
            if r.ok { "ok" } else { "err" }
35
        );
36
        out.push_str(&line); // the temporary `line` String is allocated then dropped
37
    }
38
    out
39
}
40

41
/// Optimized: preallocate the output, write in place, no per-row temporary.
42
fn render_fast(records: &[Record]) -> String {
43
    use std::fmt::Write; // brings `write!` for String into scope
44
    // Reserve a generous estimate so the buffer rarely reallocates.
45
    let mut out = String::with_capacity(records.len() * 32);
46
    for r in records {
47
        let _ = write!(
48
            out,
49
            "{},{},{:.1},{}\n",
50
            r.id,
51
            r.region,
52
            r.latency_ms,
53
            if r.ok { "ok" } else { "err" }
54
        );
55
    }
56
    out
57
}
58

59
fn main() {
60
    let records = make_records(2_000_000);
61

62
    let a = render_naive(&records);
63
    let b = render_fast(&records);
64

65
    // Same output — the optimization is purely about how we build the string.
66
    assert_eq!(a.len(), b.len());
67
    println!("rendered {} bytes from {} records", b.len(), records.len());
68
}

Running it confirms both renderers agree:

1
rendered 50126538 bytes from 2000000 records

Flame-graph this binary and you will see render_naive dominated by a format! + __rust_alloc tower (one allocation per row, two million times) plus the Drop of each temporary String. Search the SVG for alloc to see the combined percentage. After switching the call to render_fast, re-profile: the per-row allocation plateau collapses because the output String is allocated once (with_capacity) and write! formats directly into it. The flame graph makes the difference between “allocate per row” and “allocate once” visible as a shrinking box — the whole point of profiling before and after.

Tip: write!(out, ...) into an existing String is the standard Rust idiom for “format without a temporary.” It returns a Result (the fmt::Write impl for String never actually fails), which is why we discard it with let _ =. See optimization.md for more allocation-avoidance patterns.

Exercises

Exercise 1: Read a graph before you build one

Difficulty: Beginner

Objective: Practice the core skill — interpreting the shape — without any tooling.

Instructions: Suppose a flame graph shows, from bottom to top: main (100% width) → process_orders (95%) → and stacked on process_orders two boxes side by side, validate (15%) and serialize (78%). On top of serialize sits __rust_alloc (70%) with nothing above it. Answer in prose: (a) Which function should you investigate first, and why? (b) Is process_orders’s own code likely the problem? (c) What does the __rust_alloc ceiling at 70% strongly suggest the fix is?

Solution

(a) serialize (and what it calls). It is 78% of the width, far more than validate’s 15%, so the overwhelming majority of CPU time lives in the serialize subtree. Optimizing validate could at best save 15%; serialize is where the leverage is.

(b) No. process_orders is 95% wide only because its children (validate + serialize) are wide. It has almost nothing stacked as its own ceiling, so its self time is tiny — it is just a router that calls the expensive work.

(c) An __rust_alloc box that is 70% wide with nothing above it means the program is spending ~70% of its time in the allocator itself (self time in malloc/grow). That points squarely at excessive heap allocation inside serialize — repeated String/Vec allocation, clone(), collect(), or format! per item. The fix is to allocate once (e.g. String::with_capacity + write!) and reuse buffers, as in the Real-World Example above. After the fix, re-profile: that ceiling should shrink dramatically.

Exercise 2: Generate a flame graph and find the hot spot

Difficulty: Intermediate

Objective: Run the full cargo-flamegraph loop on a real program and identify the guilty function from the SVG.

Instructions: Create a binary that, given a Vec<String> of 200_000 lines, counts how many lines contain a given substring by building the lowercased version of each line with to_lowercase() and calling .contains(). Add [profile.release] debug = true to Cargo.toml, run cargo flamegraph --bin <name> (use sudo on macOS), open the SVG, and identify which standard-library function forms the widest plateau. Write down what you observe.

Solution

1
/// Count lines that contain `needle`, case-insensitively.
2
/// The per-line `to_lowercase()` allocation is the hot spot.
3
fn count_matches(lines: &[String], needle: &str) -> usize {
4
    let needle = needle.to_lowercase();
5
    let mut hits = 0;
6
    for line in lines {
7
        // Allocates a brand-new lowercased String for EVERY line — the bottleneck.
8
        if line.to_lowercase().contains(&needle) {
9
            hits += 1;
10
        }
11
    }
12
    hits
13
}
14

15
fn make_lines(n: usize) -> Vec<String> {
16
    let words = ["RUST", "Performance", "FlameGraph", "tokio", "Profiler", "node"];
17
    (0..n)
18
        .map(|i| {
19
            let mut s = String::new();
20
            for k in 0..8 {
21
                s.push_str(words[(i + k) % words.len()]);
22
                s.push(' ');
23
            }
24
            s
25
        })
26
        .collect()
27
}
28

29
fn main() {
30
    let lines = make_lines(200_000);
31
    let hits = count_matches(&lines, "flamegraph");
32
    println!("matching lines: {hits}");
33
}

1
[profile.release]
2
debug = true

1
cargo flamegraph --bin matches      # add `sudo` on macOS
2
open flamegraph.svg

What you observe: The widest plateau (its own flat ceiling) is inside str::to_lowercase and the __rust_alloc frames beneath the per-line allocation. count_matches’s own box is wide but only because of what it calls. The fix (an optimization, not part of this exercise) is to lowercase into a reused buffer or, better, do a case-insensitive comparison without allocating per line. The output is matching lines: 200000 because every generated line contains the word.

Verified to compile and run (the binary prints matching lines: 200000). Your exact SVG layout depends on the OS sampler, but to_lowercase + allocation will be the dominant tower.

Exercise 3: Confirm the fix on the flame graph and the clock

Difficulty: Advanced

Objective: Close the optimization loop — fix the Exercise 2 hot spot, re-profile, and verify both the box shrank and the program got faster.

Instructions: Rewrite count_matches to avoid allocating a new String per line. Reuse one scratch buffer, lowercasing each line into it with the to_lowercase char iterator, then call .contains(). Keep the result identical. Re-run cargo flamegraph and compare; also time both versions (/usr/bin/time or a quick loop) to confirm a real speedup.

Solution

1
/// Reuse one buffer across all lines: lowercase into `buf`, then search it.
2
fn count_matches(lines: &[String], needle: &str) -> usize {
3
    let needle = needle.to_lowercase();
4
    let mut buf = String::new(); // allocated once, reused every iteration
5
    let mut hits = 0;
6
    for line in lines {
7
        buf.clear();
8
        // `to_lowercase()` on a char yields chars; `extend` appends without a temp String.
9
        buf.extend(line.chars().flat_map(|c| c.to_lowercase()));
10
        if buf.contains(&needle) {
11
            hits += 1;
12
        }
13
    }
14
    hits
15
}
16

17
fn make_lines(n: usize) -> Vec<String> {
18
    let words = ["RUST", "Performance", "FlameGraph", "tokio", "Profiler", "node"];
19
    (0..n)
20
        .map(|i| {
21
            let mut s = String::new();
22
            for k in 0..8 {
23
                s.push_str(words[(i + k) % words.len()]);
24
                s.push(' ');
25
            }
26
            s
27
        })
28
        .collect()
29
}
30

31
fn main() {
32
    let lines = make_lines(200_000);
33
    let hits = count_matches(&lines, "flamegraph");
34
    println!("matching lines: {hits}");
35
}

1
cargo build --release
2
# Time the optimized binary (best of a few runs):
3
for i in 1 2 3; do /usr/bin/time ./target/release/matches; done

What you should see: The output is still matching lines: 200000. On the new flame graph the per-line __rust_alloc plateau under count_matches shrinks sharply because the buffer is allocated once instead of 200,000 times; the remaining cost is the unavoidable char::to_lowercase work. The wall-clock/user time drops correspondingly. For a trustworthy speedup number rather than an eyeballed one, wrap both versions in a criterion benchmark with black_box so the optimizer cannot elide the search.

This solution compiles and runs (prints matching lines: 200000). The exact timing depends on your machine, but reusing the buffer measurably beats allocating per line.

Flame Graphs with cargo-flamegraph

Quick Overview

TypeScript/JavaScript Example

Rust Equivalent

Detailed Explanation

What the picture means, axis by axis

Reading our example

From picture to fix

Key Differences

Common Pitfalls

1. Profiling a debug build (or release without symbols)

2. Reading the x-axis as a timeline

3. Blaming a wide box for time its children spent

4. Inlining makes your hot function disappear

5. The program finishes too fast to sample

Best Practices

Real-World Example

Further Reading

Exercises

Exercise 1: Read a graph before you build one

Exercise 2: Generate a flame graph and find the hot spot

Exercise 3: Confirm the fix on the flame graph and the clock