ui: render sampled stacks as a per-thread flamechart track
Sampled call stacks are currently only visible as one instant per
sample or as an aggregated flamegraph on selection; there is no way to
see how stacks evolve over time. Replace the per-thread callstack
samples track with a flamechart track: row 0 keeps one diamond marker
per sample (click to see its callstack, like the instants view it
replaces) and the rows below render the maximal-run decomposition
computed by _flamechart_runs! over the inline-expanded callstack
forest. All stack-sample markers (including the process callstacks
tracks) render as diamonds.
The flamechart only applies when the session's timebase approximates
wall time (cycles, cpu-clock, ...); event-count timebases keep the
instants view. Threads with several sampling sessions get one track
per session under a summary track, preserving per-session area
selection. All expensive work happens on the first render of the
track, so trace load pays no flamechart cost.
Frames are colored by origin, consistently across all stack-sample
surfaces: the process's own binary, shared libraries and the kernel
each get a distinct muted hue and unresolved frames are grey like the
flamegraph. Bars carry a dashed bottom hairline (RECT_PATTERN_SAMPLED),
implemented in both the WebGL shader and the Canvas2D fallback, and
tooltips mark durations as "(sampled)". Empty frame names display as
"unknown".
Stack depth is one dial ('Stack frames': No frames / 4 frames / All
frames): hidden frames sit behind a clickable grey "…" row which
steps the view up one level, so the flamechart stays discoverable from
the markers-only state. Threads with instrumented slice tracks default
to markers only; other threads default to the 4-frame peek, and only
the busiest few reveal themselves so system-wide traces with hundreds
of sampled threads stay readable.
Track naming drops the source prefix when only one source emits stack
samples, per-session splits only happen with at least two sessions,
and process callstacks tracks are skipped when they would duplicate a
single sampled thread (the common shape for kernel threads).
Perfetto is an open-source suite of SDKs, daemons and tools which use tracing to help developers understand the behaviour of complex systems and root-cause functional and performance issues on client and embedded systems.
It is a production-grade tool that is the default tracing system for the Android operating system and the Chromium browser.
Perfetto is not a single tool, but a collection of components that work together:
Perfetto was designed to be a versatile and powerful tracing system for a wide range of use cases.
ftrace, allowing you to visualize scheduling, syscalls, interrupts, and custom kernel tracepoints on a timeline.chrome://tracing. Use it to debug and root-cause issues in the browser, V8, and Blink.We‘ve designed our documentation to guide you to the right information as quickly as possible, whether you’re a newcomer to performance analysis or an experienced developer.
New to tracing? If you're unfamiliar with concepts like tracing and profiling, start here:
Ready to dive in? Our “Getting Started” guide is the main entry point for all users. It will help you find the right tutorials and documentation for your specific needs:
Want the full overview? For a comprehensive look at what Perfetto is, why it's useful, and who uses it, see our main documentation page:
For users interested in the Debian distribution of Perfetto, the official source of truth and packaging efforts are maintained at Debian Perfetto Salsa Repository
Have questions? Need help?
We follow Google's Open Source Community Guidelines.