Perfetto: tracing and profiling for Android, Chromium and native C++

What Perfetto solves, and who ends up using it

The problem is that a performance bug in a complex system rarely lives in one process. A dropped frame in an Android app involves the app's own threads, the system scheduler, CPU frequency changes and the graphics stack. Perfetto's answer is to capture all of that into a single trace file, then let you read it on one timeline. The README describes it as "a production-grade tool that is the default tracing system for the Android operating system and the Chromium browser", which is the strongest statement in the document about who already depends on it.

The README splits its audience explicitly. Android app and platform developers use it to root-cause slow startups, dropped frames (jank), animation glitches, low memory kills and ANRs, and to profile Java/Kotlin and native C++ memory with heap dumps and profiles. C and C++ developers on Linux, macOS and Windows use the tracing SDK to add custom trace points. Linux kernel and system developers use it as a userspace daemon for ftrace, to see scheduling, syscalls and interrupts. Chromium developers encounter it as the tracing backend behind chrome://tracing. Performance engineers and SREs use the SQL analysis engine on traces that did not come from Perfetto at all.

That last group is the one worth noticing. The README lists Linux perf, macOS Instruments and Chrome JSON traces as formats the analysis side can ingest. So Perfetto is two products wearing one name: a capture system, and a viewer plus query engine for traces from elsewhere.

The stack: daemons, an SDK, OS probes, a UI and SQL

The README is direct that Perfetto "is not a single tool, but a collection of components that work together", and the repository layout backs that up. The top level contains sdk/, src/, protos/, ui/, python/ and tools/, alongside build files for Bazel (MODULE.bazel, WORKSPACE), GN (BUILD.gn) and Meson (meson.build). The Android integration is visible too: Android.bp, perfetto.rc, heapprofd.rc, traced_perf.rc and perfetto_flags.aconfig sit at the root, which is consistent with the claim that this ships as part of Android rather than only as a standalone download.

The data flow is capture, store, analyze. Tracing daemons collect from many processes on one machine into a unified trace file. The SDK is a C++17 library that writes trace points directly from userspace to userspace, which is what makes low overhead possible for application-level instrumentation. OS-level probes add system context: scheduling states, CPU frequencies, memory profiling and callstack sampling, on Android and Linux. The browser UI then renders the result, and the SQL analysis library queries it programmatically.

The UI detail that matters most is in the README's own wording: it is "fully local", requires no installation, works in all major browsers, and can open traces from other tools. For anyone whose traces contain customer data or internal symbol names, that is the difference between a tool you can run on a locked-down workstation and one you cannot. The SQL engine is the other half of the same argument: it turns a one-off visual inspection into a repeatable metric extraction, which is what you need if you want to compare traces across builds.

Getting Perfetto and recording a first trace

The README does not give a command-line install procedure. Its Getting Started section points readers to the documentation site instead: the "What is Tracing?" page for newcomers, and "How do I start using Perfetto?" as "the main entry point for all users", which routes you by role (Android App Developer, C/C++ Developer, and so on). For a packaged build, the README names one place only: "For users interested in the Debian distribution of Perfetto, the official source of truth and packaging efforts are maintained at Debian Perfetto Salsa Repository". So if you want a distro package, that link is where the project sends you, not the GitHub releases page.

What the repository does show is that the project builds with Bazel, GN and Meson, and it ships a .bazelversion file at the root, so the pinned Bazel version is part of the checkout. Beyond that, the README does not document a build or install command, and this article will not invent one.

For instrumenting your own code, the README points at docs/instrumentation/tracing-sdk.md and the examples/ directory, which contains examples/README.md, examples/sdk/ and examples/shared_lib/. Those are the concrete starting points the project offers for the SDK path.

For the analysis path, the README's claim is that no installation is needed at all: the UI runs in the browser and is fully local. That is the shortest route to a first real use. Record or obtain a trace, open the UI, load the file, and you should see a timeline. If you want to query rather than look, the SQL analysis library is the component to read about next; the README does not include a worked SQL example.

Where Perfetto is the wrong tool

Perfetto's scope is the source of its main limitation. It is built for tracing many processes on a single machine into one unified trace. If your problem spans a fleet of machines, the README's own component list gives you nothing: there is no mention of distributed collection, remote aggregation or a server-side store. You would be exporting traces and correlating them yourself.

The second boundary is platform. The OS-level probes are described as capturing system-wide context "on Android and Linux". The C/C++ SDK path is listed for Linux, macOS and Windows, and the README notes that detailed CPU and native heap profiling are Linux-only. So on macOS and Windows you get application-level trace points, not the system context that makes a Perfetto trace interesting in the first place. If your performance question is about the scheduler, macOS Instruments is the tool that owns that layer, not Perfetto.

The third boundary is operational. The daemons exist as .rc files in this repository because on Android they are managed by init. Running a long-lived tracing daemon on a production Linux host is a different proposition, and the README does not document how to stop it, how to bound its disk usage, or how to roll it back once a service manager owns it. Treat that as an open question to answer before you deploy, not as a documented procedure.

Finally, if you want a profiler that answers a question in one click, Perfetto will feel like overhead. The SQL engine is powerful precisely because it makes you express what you are looking for. That is a cost, not a feature, on the first day.

Perfetto against Linux perf and macOS Instruments

The honest comparison is not Perfetto versus a competitor, because the README positions Perfetto as a consumer of the other tools' output. It states that you can analyze traces from Linux perf, macOS Instruments and Chrome JSON traces in the SQL interface. So the real question is which layer you want to own.

Linux perf is a sampling profiler tied to the kernel's perf_events subsystem. It answers "where is CPU time going" by interrupting execution at a fixed rate and attributing samples to call stacks. Perfetto's approach is different in kind: it records discrete events (trace points, scheduling transitions, state changes) and reconstructs a timeline from them. Sampling gives you statistical coverage of code you did not instrument; tracing gives you exact ordering and causality for the code you did. A slow function that is never on the stack when the sampler fires will show up in a trace and may be invisible in a profile.

macOS Instruments is the platform's own profiling environment, and it is the only one of the three that owns the macOS system layer. Perfetto's README lists macOS under the C/C++ SDK path, not under OS-level probes. If you need to know what the macOS scheduler did, Instruments is where that data lives; Perfetto can read an Instruments trace afterwards, per the README, but it is not the collector.

The practical split: reach for perf or Instruments when the question is "what is hot", and for Perfetto when the question is "in what order did this happen, and why". The README's own framing, that Perfetto helps "root-cause functional and performance issues", points at the second question.

Maintenance, licensing and what the repository tells you about cost

The last push to the default branch was on 2026-09-22, and the most recent release listed is v58.2 from 2026-08-24, preceded by v57.2 on 2026-07-07 and v57.1 on 2026-07-02. The repository is not archived. That cadence is consistent with a project that is actively developed, and the presence of CHANGELOG, TEST_MAPPING and PerfettoIntegrationTests.xml at the root suggests releases are gated by an integration test suite rather than shipped ad hoc.

Upgrade cost depends on which component you touch. The browser UI is the cheapest: it runs in the browser, needs no installation, and the README describes it as able to open traces from other tools, so a UI update does not force you to re-record anything. The SQL analysis library is next; queries are written against trace contents, so a new release that adds tables is additive for most users. The expensive part is the SDK. The README describes it as a C++17 library, which means it is compiled into your binary and your ABI and build toolchain constraints apply. If you ship an Android app that links it, a Perfetto upgrade rides along with your app release, not with a package manager.

The licence is Apache-2.0, confirmed by the LICENSE file, the MODULE_LICENSE_APACHE2 marker and the repository metadata. Apache-2.0 is a permissive licence with an explicit patent grant, which is why it is common in projects meant to be embedded in commercial products. That is a description of the licence text, not legal advice; if you are redistributing a modified Perfetto inside a product, read the NOTICE and attribution requirements with your own counsel. Note also that the README points Debian users at a separate Salsa repository as "the official source of truth and packaging efforts", so a Debian package and a GitHub release are not the same artifact and may not move together.

Editorial conclusion

Adopt Perfetto if you need a unified trace across many processes on one machine, if you target Android or Chromium, or if you want to query traces with SQL instead of clicking through a viewer. Do not adopt it as your first profiling tool if you only need a quick CPU flame graph from a single process, or if your target is a platform the README does not list (Android, Linux, macOS, Windows, and Chromium). Before committing, verify two things on your own machine: that the tracing daemon captures the OS-level probes you need on your kernel, and that the browser UI opens your trace size locally, since the README states the UI is fully local and opens multi-GB traces but the repository does not document a rollback path for the daemon once it is running under a service manager.

Frequently asked questions

Official sources

1. google/perfetto on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases