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 states that "It is the default tracing system for Android and Chromium", 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, jank, ANRs and low memory kills, and to profile Java/Kotlin and native memory. C, C++ and Rust developers use the tracing SDKs 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 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 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 tracing SDK (C++ or Rust) writes your app's trace points with low overhead. 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 "needs no install and runs fully locally: traces are not uploaded anywhere", and it 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 has a Quick start with commands. On Android, with a device connected over adb, you download tools/record_android_trace with curl and run `python3 record_android_trace -o trace.pftrace -t 10s sched freq gfx view am wm`; the trace opens in the Perfetto UI when recording finishes. On Linux, you download tracebox from get.perfetto.dev plus the test/configs/scheduling.cfg config and run `sudo ./tracebox -o trace.pftrace --txt -c scheduling.cfg`. For Chrome, the README points to the recording page in the UI. If you are unsure where to start, "How do I start using Perfetto?" on the documentation site picks a path based on what you want to do. For a distro package, the README says the Debian packaging is maintained in the Debian Perfetto Salsa repository.

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.

For instrumenting your own code, the README links the C++ tracing SDK and Rust SDK docs on perfetto.dev and the in-app tracing guide, and the repository has an 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 README downloads trace_processor and runs `./trace_processor query trace.pftrace` with a SQL query against the slice table, or uses `pip install perfetto` and `TraceProcessor(trace='trace.pftrace')` from Python.

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 README says system-wide recording works on Android and Linux, while the tracing SDK, the UI and Trace Processor also run on macOS and Windows. 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 Android developers use it to "root-cause slow startups, jank, ANRs and low memory kills", 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-11-02, and the most recent release listed is v59.1 from 2026-10-27, preceded by v58.2 on 2026-08-24 and v57.2 on 2026-07-07. 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 C++ and Rust SDKs for instrumenting your own code, 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 licence's attribution requirements with your own counsel. Note also that the README says the Debian packaging is maintained in a separate Debian Perfetto Salsa repository, 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