Flame Graph
Native flame graphs from folded-stack input (semicolon-separated frames + a sample count). Frame width is proportional to total samples and depth grows upward, coloured warm by frame. The standard tool for CPU / performance profiling.
In the same space
Most users come to Flame Graph from speedscope or Brendan Gregg flamegraph.pl. flowss runs this engine in the browser — no install, shareable via URL, exportable to PNG / SVG / PDF / source.
Syntax at a glance
main;parse;tokenize 20
main;eval;apply 30Paste this in the Studio code pane to see Flame Graph render live. The full grammar is at the upstream-docs link above.
Sample templates
All 8 →Where time goes serving a request.
Time spent across build phases.
Cost of each startup step.
A 2,800-sample py-spy profile of POST /checkout/ under load: 45.8% of wall time is waiting on PostgreSQL, and the single widest tower is the promotions engine re-querying the database for every basket line (23.4%) — an N+1 the fix for which is one prefetch. The payment gateway call (19.1%) is network wait the service cannot shorten. Illustrative values.
A 30-second pprof CPU profile of a Go pricing service at 1,800 requests per second (6,680 samples): regular expressions take 45.7% of the CPU, 18.2% of it recompiling the same rule patterns on every call, and garbage collection plus allocation take another 26.6% — the pattern that says "compile once at load, cache the *regexp.Regexp". Illustrative values.
perf samples from the one backend running a 41-second month-end revenue report (4,360 samples): 50.5% is a sequential scan feeding the hash join's build side, 18.8% of it waiting on reads from disk, and the sort that spills to temporary files costs a further 20%. Planning is 1.1% — the plan is the problem, not the planner. Illustrative values.
flamegraph · ← Browse all engines · Quick-start guide