Performance
Hot paths: free-recall review
Retrieval beats re-reading. For each prompt, say or write a full answer from memory before you open the model answer — the effort of recall is what makes the diagnostic loop stick.
Reconstruct the unit’s spine without looking back: why a wide leaf is only a symptom, the five shapes and their signatures, how the parent/child chain locates the fix, when hardware counters decide, the fix-and-verify loop, and where regressions actually hide.
- 01Why is naming the wide leaf not enough, and what else must you read before choosing a fix?
- 02List the five hotspot shapes, each with one profile signature and its fix family.
- 03How do the parent chain and the child chain each locate where to apply the fix?
- 04When do you reach for hardware counters instead of just reading the flame graph, and what do they reveal?
- 05State the fix-and-verify loop and what each of its two failure outcomes means.
- 06Why do hot-path regressions hide in tail latency rather than mean CPU%, and how do you catch them?
If you reconstructed each answer from memory, you hold the unit’s diagnostic loop: a wide leaf is a symptom, not a cause; classify it into one of the five shapes (plus JIT deopt and the counter-only cases — false sharing, native bridge); the parent chain decides caller-fix vs leaf-fix and the child chain decides this-layer vs one-level-down; hardware counters and TMA resolve compute-vs-memory ambiguity; the fix-and-verify loop demands local-and-headline evidence; and regressions hide in the tail, not the mean. Diagnose first, fix one thing, prove it.