Performance
Profile first: multiple-choice review
Crux Multiple-choice synthesis across the profile-first unit — Amdahl ceilings, self vs cum-time, measurement scopes, the observer effect, statistical baselines, and flame-graph shape reading.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each one mirrors a decision you make in a real “the service is slow” investigation — not a definition to recite, but a judgement call to defend with numbers.
Goal
Confirm you can connect the measurement loop, Amdahl’s ceiling, scope selection, the observer effect, statistical reporting, and flame-graph reading — the synthesis the individual lessons built toward.
Quiz
Completed
A profile shows your top function at 12% of total CPU. A teammate proposes a heroic rewrite that would make it 8x faster. Before approving, what is the decisive number and what does it say?
Heads-up Local speedup is meaningless without the share. Amdahl bounds total improvement by p; an 8x win on a 12% function buys ~12% total, not 8x.
Heads-up Amdahl lets you predict the ceiling before writing a line. Shipping a risky rewrite to discover a 1.12x ceiling you could have computed is exactly the waste profile-first prevents.
Heads-up Self-time tells you WHERE the work is, not whether the win is worth it. A function can be 100% self-time and still only 12% of total — Amdahl still caps the win at ~12%.
Quiz
Completed
A flame graph shows one function with cum-time 80% but self-time 2%, sitting above a single wide leaf. What is it, and where does the fix live?
Heads-up Cum-time includes callees. With 2% self-time the function's own instructions barely cost anything; rewriting it saves at most 2%. The real cost is in what it calls.
Heads-up Huge cum-time with tiny self-time is the normal, expected signature of HTTP handlers, middleware, and dispatch layers. It is a reading instruction, not an error.
Heads-up Flame-graph x-position is alphabetical grouping, not time order. Left-vs-right says nothing about execution sequence; width is sample count.
Quiz
Completed
A microbenchmark says a new hash is 10x faster. You want to know if your API will get faster. Which measurement answers that honestly, and why?
Heads-up Iterations fix variance, not scope. A microbench measures the function in isolation and can never tell you its share of API wall-clock — that requires a production profile.
Heads-up If hashing is 3% of API time, Amdahl caps the gain at ~1.03x — invisible to users. Reasoning by category ('hashing is a common bottleneck') instead of measuring share is the original sin profile-first prevents.
Heads-up A macrobench validates end-to-end but depends on synthetic load matching real traffic; it is a final check, not the share measurement. The production profile is the honest source of p.
Quiz
Completed
An instrumentation profiler reports a hot Java method at 40 ms/call; a sampling profiler reports 8 ms/call for the same method. Which reflects production, and what causes the gap?
Heads-up Exact call counts only help when measurement cost is negligible. In a JIT runtime, instrumentation disables inlining and adds 20–100% overhead, so it measures a different (slower) program than production runs.
Heads-up Same method, same units (ms/call), wildly different numbers because of different perturbation levels. The observer effect makes them measure different systems; sampling is the production-representative one.
Heads-up Hardware counters explain WHY a function is hot (memory- vs compute-bound); they do not resolve the instrumentation-overhead gap. Sampling does.
Quiz
Completed
A PR claims '15% faster' from one staging run. A second engineer reruns the same code unchanged and sees a 7% swing. How do you read the original claim?
Heads-up Controlled does not mean noise-free. Staging still has GC pauses, scheduler decisions, and cache-state variation producing 5–10% swings between identical runs, as the rerun just demonstrated.
Heads-up Two runs cannot establish a distribution, and mean is the wrong statistic — it is dominated by outliers and hides the tail. You need the median, p95/p99, and a CI across at least 5 runs.
Heads-up The swing proves the measurement is noisy, not that the change is bad. Neither run is trustworthy alone; you cannot judge sign or magnitude without a distribution.
Quiz
Completed
A flame graph shows thin spikes scattered across the full width with no dominant leaf, yet p99 latency is terrible. What does the shape tell you and what do you capture next?
Heads-up Scattered thin spikes are a recognisable, valid shape meaning the time is not on-CPU. It is a diagnosis, not a malfunction.
Heads-up Flat CPU means the bottleneck is off-CPU, not absent. With bad p99 the time is going somewhere — into waiting, which a CPU profile is blind to.
Heads-up A higher rate renders the same scattered shape more densely; it cannot consolidate off-CPU time into a CPU hotspot because that time was never on-CPU.
Recap
The unit’s through-line is one investigation: quantify the complaint, reproduce under realistic load, capture a baseline, read the SHAPE before the names, and let the numbers — not intuition — name the hotspot. Amdahl’s ceiling decides whether a fix is worth it (share beats local speedup); self vs cum-time decides where to look; scope selection and the observer effect decide which measurement to trust; statistical baselines decide whether a “win” is real; and a scattered flame graph tells you the bottleneck is off-CPU. Every wrong answer above is a real way engineers fool themselves into optimising the wrong code.