HierarchyIntermediate

Flame Map

The aggregated cousin of the flame chart — identical call stacks are merged so that width represents total time spent, revealing the hottest code paths at a glance.

// 01 — The chart

What it looks like

Example — Aggregated CPU profile of a web server (5 s sample)
all (100%)handleRequest() — 60%gcCollect() — 23%idle — 15%queryDB() — 36%serialize() — 24%tcpSend() — 22%parse() — 14%

A flame map of a web server profile. Width = percentage of total CPU time. The widest bar at each level is the biggest time consumer.

// 02 — Definition

What is a flame map?

A flame map (commonly called a flame graph) is an aggregated visualization of profiled call stacks. Unlike a flame chart, it does not preserve chronological order. Instead, it merges every occurrence of the same stack trace into a single bar whose width is proportional to the total time (or sample count) spent in that stack.

The result is a compact overview that answers the question: “Where is my program spending the most time overall?” The widest bars are the hottest code paths. Children sit on top of parents, so you can trace the full call chain from entry point to the function consuming CPU cycles.

Flame maps were popularized by Brendan Gregg at Netflix in 2011. They have since become a standard tool in systems performance engineering across Linux, Java, Node.js, Go, and virtually every other runtime.

Naming note: The term “flame graph” (Brendan Gregg’s original name) is the most common in the industry. We use “flame map” to distinguish it from the time-ordered flame chart, but the visualization is the same.

// 03 — Anatomy

Parts of a flame map

root (100%)hot_fn() — 63%other() — 37%child_a()child_b()A — Root frame (full width)B — Width = total timeC — Merged childrenx-axis = alphabetical / arbitrary (NOT time)
A — Root frame: The bottom bar spanning the full width — represents all samples (100% of time)
B — Width: Each bar’s width encodes total CPU time (or sample count) spent in that stack path
C — Merged children: All occurrences of the same function called from the same parent are merged into one bar

// 04 — Usage

When to use it — and when not to

✓Use a flame map when…
  • You need a high-level summary of where CPU time is spent across a profile
  • Comparing two profiles (before/after optimization) using a differential flame graph
  • The profile spans minutes or hours and a time-ordered chart is too compressed
  • Communicating performance bottlenecks to teammates in a single image
  • Profiling backend servers where temporal ordering matters less than aggregate cost
  • Analyzing memory allocations, I/O waits, or off-CPU time (with appropriate profilers)
×Avoid a flame map when…
  • You need to see the exact chronological sequence of events — use a flame chart instead
  • The data is not call-stack-based (e.g., network traces, project timelines)
  • You want to show organizational hierarchy — use an org chart or tree diagram
  • The profile has very few unique stacks — a simple table of function times is clearer
  • Your audience has no familiarity with call stacks or code execution concepts
  • You need to visualize quantities (budget, revenue) rather than time-on-CPU

// 05 — Reading guide

How to read a flame map

The key rule: width = time cost, depth = call chain.

1

Start at the bottom

The bottom bar spans the full width and represents the total profile. Every stack starts here.

2

Find the widest bars

Wider means more CPU time. The widest bars at any given level are your primary optimization targets.

3

Trace upward from wide bars

Follow the stack upward to see which child functions are consuming that time. The top-of-stack (leaf) frames are where the CPU is actually executing.

4

Ignore the x-axis ordering

Unlike a flame chart, the left-to-right order is arbitrary (usually alphabetical). Only width matters, not horizontal position.

5

Look for plateaus

A bar that is the same width as its parent means the parent spends all its time in that one child — the parent is essentially a pass-through.

// 06 — Pitfalls

Common mistakes

Reading the x-axis as a timeline

Fix: The x-axis is NOT chronological in a flame map. Left-to-right order is arbitrary. Only width has meaning.

Assuming color has semantic meaning

Fix: Colors are typically random or hash-based to distinguish adjacent bars. They do not encode hot/cold unless a differential scheme is applied.

Focusing on top-of-stack only

Fix: While leaf frames show where the CPU executes, the parent frames show why. Trace the full path for context.

Comparing two profiles visually without diffing

Fix: Use a differential flame graph tool (red/blue coloring) rather than comparing two images side-by-side.

Forgetting to filter runtime/GC noise

Fix: Profilers often include runtime internals. Filter to user-space functions first to see actionable bottlenecks.

// 07 — In the wild

Real-world examples

Netflix cloud infrastructure profiling

Brendan Gregg invented flame graphs at Netflix to diagnose performance regressions in production microservices.

Linux perf + FlameGraph scripts

The most common workflow: capture stack samples with `perf record`, then generate an SVG flame graph.

Speedscope (web viewer)

A browser-based profiler viewer that renders flame maps from Chrome, Node.js, and Ruby profiles.

Go pprof

Go’s built-in profiler outputs flame graphs showing CPU and memory allocation hotspots.

Continuous profiling platforms

Tools like Pyroscope, Parca, and Datadog Continuous Profiler aggregate flame graphs over time for production monitoring.

// 08 — At a glance

Quick reference

Also known asFlame graph, flamegraph, stack graph
CategoryHierarchy
Typical dataAggregated CPU profiler samples, memory allocation stacks
X-axisArbitrary (alphabetical) — NOT chronological
Y-axisCall stack depth (callers at bottom, callees on top)
Width encodesTotal time / sample count for that stack path
Invented byBrendan Gregg, Netflix (2011)

// 09 — Variations

Variations

Icicle graph (inverted flame graph)

Root at top, children growing downward. Same data, opposite orientation.

Differential flame graph

Compares two profiles: bars colored red (slower) or blue (faster) to highlight regressions.

Off-CPU flame graph

Shows time spent waiting (blocked I/O, locks, sleep) rather than on-CPU execution.

Memory flame graph

Width encodes bytes allocated rather than CPU time, revealing memory hotspots.

// 10 — FAQs

Frequently asked questions

What is a flame map?+

A flame map (commonly called a flame graph) is an aggregated visualization of profiled call stacks. Unlike a flame chart, it does not preserve chronological order. Instead, it merges every occurrence of the same stack trace into a single bar whose width is proportional to the total time (or sample count) spent in that stack.

When should you use a flame map?+

Use a flame map when you need a high-level summary of where CPU time is spent across a profile. It also works well when comparing two profiles (before/after optimization) using a differential flame graph, and when the profile spans minutes or hours and a time-ordered chart is too compressed.

When should you avoid a flame map?+

Avoid a flame map when you need to see the exact chronological sequence of events — use a flame chart instead. It is also a poor fit when the data is not call-stack-based (e.g., network traces, project timelines), or when you want to show organizational hierarchy — use an org chart or tree diagram.

Is a flame map suitable for dashboards?+

Yes — a flame map can work well in dashboards as long as the panel is large enough for readers to perceive the encoded values, has a clear title, and includes the legend or axis labels needed to interpret it.

What category of chart is a flame map?+

Flame Map belongs to the Hierarchy family of charts. Charts in that family are designed to answer the same kind of question, so they often work as alternatives when one doesn't quite fit your data.

How do you read a flame map?+

Start with the axis labels and legend, then look at the overall shape before zooming into individual marks. Compare prominent features against the rest of the data, and verify any conclusion against the underlying numbers when precision matters.