| Oddly enough I've generated similar graphs for stack tracing and profiling in the far far distant past and had not realised they'd been named and formalised. For anyone else who has not recognised the name, I found these origin links which may interest some: Abstract [2]:
Flame graphs are a simple stack trace visualization that helps answer an everyday problem: how is software consuming resources, especially CPUs, and how did this change since the last software version?
Flame graphs have been adopted by many languages, products, and companies, including Netflix, and have become a standard tool for performance analysis.
They were published in "The Flame Graph" article in the June 2016 issue of Communications of the ACM, by their creator, Brendan Gregg.
[1] https://www.brendangregg.com/flamegraphs.html[2] https://www.usenix.org/conference/atc17/program/presentation... (hour long usenix talk of [2]) https://www.youtube.com/watch?v=D53T1Ejig1Q This paper appears to be formalising the nature of a flame graph, recognising that they rest on data from sampling profilers and as such suffer a "never the same twice" variation when repeatedly run, and thus seeking to quantify "distance" of one graph from another as well as "average" of multiple graphs (for the "one true mean reference graph" I guess). The motivation is then to be able to reliably measure "distance" from one group of profiling runs to another, before and after changes of interest. I dare say much more is possible, but I fear I've barely skimmed the material before bedtime :/ |