Profiling: free-recall review
Free-recall prompts across the profiling unit. Answer each in your own words first, then reveal the model answer and compare.
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 material stick.
Reconstruct the unit’s core mechanisms — sampling vs instrumentation, the profile-type map, the flame-graph axis, continuous profiling, eBPF symbolization, and sampling’s blind spots — without looking back at the lessons.
- 01Why is a sampling profiler viable for always-on production profiling while an instrumentation profiler is not?
- 02Name the main profile types and the one question each answers.
- 03What does the x-axis of a flame graph actually encode, and what is the most expensive misread?
- 04What does continuous profiling give you operationally that on-demand profiling cannot, and roughly what does it cost?
- 05Why does an eBPF profiler symbolize Go and Rust cleanly but show [unknown] frames for Python and partial frames for the JVM?
- 06Give two sampling blind spots a senior engineer must keep in mind before trusting the absence of a peak in a flame graph.
If you could reconstruct each answer from memory, you hold the unit’s spine: sampling buys bounded overhead at the price of exactness; each profile type answers one question and the CPU/wall ratio routes you to the right one; the flame-graph x-axis is alphabetical, never time; continuous profiling makes the incident’s flame graph pre-saved at 2-5%; eBPF symbolization depends on the runtime; and sampling’s blind spots (sub-interval hot paths, low-count noise) mean a missing peak is never proof of a missing bottleneck.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.