Profile Rust Code

Topic Overview

Measure Before You "Optimize"

Rust is fast by default, but hot paths still need data. Linux perf samples CPU stacks; cargo flamegraph wraps it into an SVG where width means time. Cloudflare and Discord publish wins found exactly this way.

bashCopy
Loading…

• Always profile --release; debug builds distort inlining and arithmetic
• Wide plateaus in the flamegraph are functions worth attention
• criterion microbenches guard against optimizing noise

Reading the Output

perf report sorts symbols by sample count. If 40% lands in memcpy, fix allocation patterns before tweaking algorithms. If a mutex shows up wide, fix contention.

For this exercise, you will profile a small CPU-heavy program and name the top frames. This task asks you to propose one change backed by numbers, because profiling culture is what separates Rust marketing from Rust performance in production.

Keep the relevant man page, ABI doc, or Rust reference chapter open while you work. When your output disagrees with the reference implementation on the same machine, the mismatch is usually an alignment rule, an off-by-one terminator, or a register slot you misread in GDB. Skim the official documentation for the tool or ABI named in the exercise; the prose changes, but register roles, syscall numbers, and ownership rules stay stable across releases.

Your Task

perf, cargo flamegraph and samply all work the same way. They interrupt the program thousands of times per second, record the call stack, and aggregate the samples. Write the aggregation half: read stack samples in the folded format that flamegraph tools use, and produce the reports a profiler shows. Getting recursion right is the classic trap: a function that appears three times in one stack was still only on the stack for one sample.

Input

cCopy
Loading…

Limits: frame names of 1..31 characters, at most 32 frames per stack, 64 distinct functions and 256 distinct stacks.

Definitions

• self(f): samples whose leaf (last frame) is f. total(f): samples whose stack contains f at least once, so recursion is not double counted.
• Percentages are relative to all samples, with one decimal, rounded half up.
• folded: identical stacks are merged (their counts are added). Print STACK COUNT lines sorted by the stack text in byte order, so a stack sorts before its own extensions (main 1 before main;parse 1).
• hot path: start with an empty prefix. Among the stacks that extend the current prefix, add up the samples by the next frame, pick the frame with the most samples (ties to the smaller name), and append it. Stop when no stack extends the prefix. Each frame shows its samples as a percentage of all samples.
• calls: every occurrence of NAME in a stack is an edge. Its caller is the frame before it (<root> if it is first), and its callee is the frame after it (if any). Each edge counts that stack's samples, so recursion shows up as eval calling eval. List them by count (descending), then by name, with <root> after equal-count names.

Output

cCopy
Loading…

• flat, folded and hot with no samples print no samples.
• calls for an unknown function prints NAME: not in any sample.
• Errors:
  • error: bad stack STACK (empty or long frame, too deep, or too many functions; nothing is recorded);
  • error: bad count X;
  • error: too many stacks;
  • error: bad command: LINE.

Example

Input:

cCopy
Loading…

Output:

cCopy
Loading…

Requirements

1. Merge identical stacks as they arrive, and derive every report from the merged table.
2. Count total once per sample, no matter how often the function appears in its stack.

Hidden tests cover deep recursion, repeated stacks that must merge, hot-path ties, flat N, reset, and malformed samples.