4.5.24 · D2Software Engineering

Visual walkthrough — Performance profiling — CPU, memory, I - O profiling

2,065 words9 min readBack to topic

We assume nothing. If you can read a ruler, you can follow line one.


Step 1 — Draw the whole program as one bar

WHAT we did: turned "how long the program takes" into a picture — a ruler of length .

WHY: every symbol we introduce next will be a piece of this bar. If we can point at a piece, we can never sneak in an undefined quantity. Fractions of the bar are exactly the "80/20" language the parent note keeps using — now they have a picture.

PICTURE: the amber bar below is the entire run. Its full width means .

Figure — Performance profiling — CPU, memory, I - O profiling

Step 2 — Cut the bar where your optimization can reach

WHAT we did: split the single bar into "attackable" () and "leftover" ().

WHY the subtraction and nothing fancier? Because the pieces are complementary — they tile the bar with no gap and no overlap. The moment you name one piece , the other is forced to be . No extra tool needed; it's just "the rest of the ruler."

PICTURE: the cyan piece is (your target), the white piece is (untouchable). Together they still span the full bar.

Figure — Performance profiling — CPU, memory, I - O profiling

Step 3 — Shrink only the slice you can reach

WHAT we did: replaced the cyan piece with a shorter cyan piece .

WHY divide, not subtract? Because "faster" is multiplicative, not additive. Running twice as fast doesn't remove a fixed chunk of time — it halves whatever was there. Halving is ; running faster is . This is the one place a division (a ratio tool) enters, and it enters precisely because speed is defined as work-per-time — a ratio.

PICTURE: watch the cyan piece collapse from to while the white piece refuses to budge.

Figure — Performance profiling — CPU, memory, I - O profiling

Step 4 — Measure the new, shorter bar

WHAT we did: added the two current pieces to get the length of the new bar.

WHY add? Because time laid end to end simply adds — that is what "total elapsed time" means on a ruler. No overlap between the pieces means no double counting.

PICTURE: the two bars stacked — original () on top, shrunken () below — so you can literally see how much shorter you made the run.

Figure — Performance profiling — CPU, memory, I - O profiling

Step 5 — Turn "shorter" into a speedup number

WHAT we did: divided the original bar () by the new bar ().

WHY this is the payoff: every quantity in this boxed formula was drawn as a piece of a ruler before it appeared. Nothing was assumed. This is the central result the parent note quotes — and now you own its picture.

Figure — Performance profiling — CPU, memory, I - O profiling

Step 6 — The edge cases (never leave the reader guessing)

Every honest derivation walks its own extremes. Here they are, each a corner of the same picture.

PICTURE: the ceiling curve. Height is the best possible speedup as the target fraction slides from to . See how flat it stays for small and how it explodes only as .

Figure — Performance profiling — CPU, memory, I - O profiling

Step 7 — Plug in real numbers (the parent's Example 1)

Reveal-to-test:

The two numbers you must extract from a profiler before applying Amdahl
the fraction of runtime in the target code, and the achievable speedup of that code.
Why a small kills the optimization even when is huge
the ceiling is close to , so the untouchable white piece dominates the new bar.

The one-picture summary

Everything above, compressed into a single diagram: the original bar of length , its split into white and cyan , the cyan piece collapsing to , and the resulting speedup — with the four edge cases pinned to their corners.

Figure — Performance profiling — CPU, memory, I - O profiling
Recall Feynman: the whole walkthrough in plain words

Picture your program's runtime as one chocolate bar. You can only re-melt part of it — say the cyan chunk — to make it faster; the white chunk is set in stone. Making the cyan chunk times faster doesn't chop off a fixed piece — it shrinks that chunk to of its size (twice as fast = half as long). Lay the leftover white chunk next to the shrunken cyan chunk: that's your new, shorter bar. Divide the old full bar by this new one and you get — how many times faster the whole thing is. The punchline lives in that stubborn white chunk: if the cyan part you can fix was small to begin with, the white part barely moved, so the bar barely shrank. That's why smart engineers measure first — they hunt for the biggest cyan chunk, because Amdahl's ruler proves that fixing a small one is a waste of a weekend. See also Flame Graphs to find the fat chunk, and Benchmarking vs Profiling to know which stopwatch you're holding.

Recall Where this connects
  • Amdahl's Law — the formula we just built from a ruler.
  • Big-O Complexity — tells you how a slice grows; Amdahl tells you whether shrinking it is worth it.
  • Flame Graphs — the visual profiler output whose bar widths are the values here.
  • N+1 Query Problem & Caching Strategies — common fat cyan chunks worth optimizing.
  • Observability — Logs, Metrics, Traces — where you get the timings in production.