Flame Graph
A visualisation of sampled stack traces in which width represents time spent, used to identify where a program's execution actually goes.
Each box is a stack frame; width is the proportion of samples containing that frame; boxes stack upward following call relationships. The horizontal axis is not time — it is alphabetically ordered so that identical frames merge.
Reading it: look for wide boxes, not tall stacks. A wide box near the top is a function consuming time directly. A wide box lower down with narrow children is time spent in that frame itself. Deep narrow towers are irrelevant regardless of how alarming they look.
What it reveals that metrics and traces cannot: metrics say a service uses 80% CPU; a trace says a span took 400 ms; only a profile says which function is responsible. Findings are frequently mundane and valuable — JSON serialisation at 30% of CPU, logging at 15%, a regular expression compiled inside a loop.
Differential flame graphs — comparing two profiles and colouring the difference — localise a regression between versions in minutes, and are the highest-value form for ongoing operations.
Variants worth knowing: off-CPU flame graphs, which show time spent blocked rather than executing, and are the tool for the common case of low CPU with high latency — lock contention, pool exhaustion, synchronous I/O.