I was in­ves­ti­gat­ing the per­for­mance of a web app today, and I spent some time looking at the Flame Chart vi­su­al­iza­tion in Chrome’s profiling tools, which helped identify some problems.

Flame Charts are like Brendan Gregg’s Flame Graphs, except that the charts are sorted by time, while the graphs are sorted al­pha­bet­i­cal­ly.

Quoting from Gregg’s recent ACM Queue article:

A flame graph has the following char­ac­ter­is­tics:

• A stack trace is rep­re­sent­ed as a column of boxes, where each box represents a function (a stack frame).
• The y-axis shows the stack depth, ordered from root at the bottom to leaf at the top. The top box shows the function that was on-CPU when the stack trace was collected, and everything beneath that is its ancestry. The function beneath a function is its parent.
• The x-axis spans the stack trace collection. It does not show the passage of time, so the left-to-right ordering has no special meaning. The left-to-right ordering of stack traces is performed al­pha­bet­i­cal­ly on the function names, from the root to the leaf of each stack. This maximizes box merging: when identical function boxes are hor­i­zon­tal­ly adjacent, they are merged.
• The width of each function box shows the frequency at which that function was present in the stack traces, or part of a stack trace ancestry. Functions with wide boxes were more present in the stack traces than those with narrow boxes, in proportion to their widths.

Flame graphs are a clever, in­for­ma­tion-dense way to present computer per­for­mance. I suspect Edward Tufte would approve.