6 exercises — read flame graphs and memory profiler output, and describe hotspots, self/total time, and allocation pressure with the correct terminology.
0 / 6 completed
1 / 6
A CPU profiler flame graph shows a wide, flat bar labelled `JSON.parse` taking up 40% of total sample width near the top of the stack. How do you correctly describe this in English to your team?
"Hotspot" is the standard term for a function that consumes a disproportionate share of CPU time. In a flame graph, width represents the proportion of samples (time), and a wide bar near the top of the stack (furthest from `main`) means the time is spent inside that function itself, not its children — this is called "self time" as opposed to "total time."
Key vocabulary: "hotspot" (disproportionate time consumer), "self time" (time in the function itself), "total/cumulative time" (time including children), "wide bar" (proportion of samples), "stack depth" (how deep in the call chain).
2 / 6
You see a very tall, narrow tower in a flame graph with dozens of stacked frames. What does this shape indicate, and how should you describe it?
In a flame graph, height represents call stack depth, while width represents time/sample count. A tall, narrow tower means deep recursion or nesting that consumes relatively little CPU time — worth noting for code complexity but not necessarily a performance concern.
Vocabulary: "deep call stack" / "deeply nested calls" (height), "narrow" (low time cost despite depth), distinguish this explicitly from a "wide" bar (high time cost). Conflating depth with cost is a common mistake when reading flame graphs for the first time.
3 / 6
A memory profiler shows retained heap growing steadily across GC cycles for a specific object type: `EventListener`, from 2MB to 400MB over 10 minutes without ever decreasing. How do you describe this correctly?
"Monotonically growing" (never decreasing, even across GC) is the key signal that distinguishes a genuine memory leak from normal fluctuating memory usage. If memory grows and then drops after GC, that's expected garbage collection behaviour; if it grows and stays high across multiple GC cycles, objects are being retained unintentionally — typically due to dangling references (e.g. an event listener that was never removed).
Vocabulary: "retained size / retained heap" (memory kept alive by references), "growing monotonically" (never decreasing), "GC cycle" (garbage collection pass), "dangling reference" (a reference preventing collection unintentionally), "detached DOM node" (a common browser-specific leak pattern).
4 / 6
A profiler shows a function with high "total time" but low "self time." How should you correctly interpret and describe this to a colleague?
This is one of the most common profiler-reading mistakes: optimising a function with high total time (which includes everything it calls) instead of drilling down to find where self time is actually high.
Vocabulary: "self time / exclusive time" (time in the function's own code, excluding calls it makes), "total time / inclusive time" (self time + all descendants' time), "drill into / expand" (navigating into child frames in the flame graph). The correct workflow is always: find high total time → drill into children → find where self time is actually concentrated → that's your real optimisation target.
5 / 6
You compare two flame graphs — before and after an optimisation. Which language correctly communicates the result to your team?
A strong before/after comparison names the specific hotspot, gives quantified percentages for both states, and connects the change back to the underlying fix (memoisation) so the causal story is clear, not just "it looks different."
Formula: "The [function] hotspot shrank from [X%] to [Y%] of total CPU time — [confirms/suggests] that [specific fix] eliminated [specific cause]." This is the language expected in performance PR descriptions and postmortems where profiler evidence needs to justify an engineering decision.
6 / 6
You notice most CPU samples in a profiler are attributed to a frame labelled `(garbage collector)` or `GC`. How should you describe this observation?
High GC time is a strong signal of allocation pressure — the application is creating (and immediately discarding) too many objects, forcing the garbage collector to run frequently. The correct response is not to disable GC (not possible/advisable in most managed runtimes) but to reduce allocations in the hot path — e.g. object pooling, avoiding unnecessary intermediate arrays, or reusing buffers.
Vocabulary: "allocation pressure" (rate of object creation stressing the GC), "hot path" (frequently executed code), "object pooling / reuse" (a common mitigation), "short-lived objects" (objects that die quickly, often the main GC cost driver).
What does the "Profiler Output Vocabulary" exercise practise?
Practise reading and describing profiler output: flame graphs, hotspots, self vs. total time, memory leaks, and GC pressure in professional English. 6 exercises.
How many questions are in this exercise?
This exercise has 6 questions, each multiple-choice with a full explanation shown after you answer.
What English level is this exercise for?
This exercise is tagged Advanced. If the vocabulary feels difficult, browse the Debugging Language category page for an easier module to start with.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free with no account, sign-up, or paywall.
Do I get feedback if I answer incorrectly?
Yes — whichever option you choose, right or wrong, you'll immediately see an explanation clarifying the correct term and why the other options don't fit.
Can I retry this exercise?
Yes — once you finish all the questions, a "Try again" button on the results screen resets the exercise so you can practise as many times as you like.
Do I need an account to track my progress?
No account is required. Your progress bar and score for this session are tracked in the browser as you go, but nothing is saved once you leave the page.
Is "Profiler Output Vocabulary" part of a larger series?
Yes — it's one exercise in the Debugging Language category on CoderSlingo. See the category page for the full list of related exercises on similar terminology.
Can I link directly to this exercise?
Yes — this exercise has its own permanent URL, so you can bookmark it or share the link directly with a colleague or study partner.
Where can I find more exercises like this one?
See the Debugging Language category page for related exercises, or browse the main Exercises hub for other IT English topics.