8 templates
Flame Graph templates
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.
HTTP Request Profile (Flame Graph)
Where time goes serving a request.
Operations & OpsBuild Time Profile (Flame Graph)
Time spent across build phases.
Operations & OpsApp Startup Profile (Flame Graph)
Cost of each startup step.
Operations & OpsFlame Graph — Django Checkout Endpoint (py-spy, wall clock)
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.
Operations & OpsFlame Graph — Go gRPC Pricing Service (pprof CPU)
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.
ArchitectureFlame Graph — PostgreSQL Backend Running a Slow Report Query (perf)
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.
Data & SchemaFlame Graph — PyTorch Training Loop, Main Process (py-spy)
Where the Python main process of a ResNet-50 training run spends its time (4,760 samples): 45% blocked waiting for the DataLoader queue, so the GPU is starved by JPEG decoding in too few workers, and a further 15.1% stalled in a per-step loss.item() that forces a CUDA synchronise. Forward, backward and the optimiser together are only 33.5%. Illustrative values.
AI & PipelinesFlame Graph — Node.js Server-Side Rendering of a Category Page
A --cpu-prof capture of a Node.js server rendering a 120-product category page (3,220 samples): 19.9% goes to constructing a new Intl.NumberFormat for every price, the 25.9% spent parsing and re-serialising the catalogue payload says the page ships far more data than it shows, and garbage collection takes 14%. Illustrative values.
Architecture