System Trace Analysis
Read Perfetto Traces Without Living in the Timeline
A Perfetto trace holds millions of slices across every thread, CPU, and counter. logcat.ai opens the trace as structured, queryable data and reasons across frames, scheduling, binder, and power, surfacing the stall behind the jank, not just the wall of tracks.
Why Perfetto Traces Are Hard to Read
The data is all there — finding the one stall is the problem
Millions of Slices
A few seconds of tracing yields millions of slices across hundreds of threads and every CPU. The UI renders it; finding the regression in it is on you.
SQL or Nothing
Real answers live in trace_processor SQL: joins across slice, sched, and thread_state. Powerful, but a language and schema most engineers touch once a quarter.
Cross-Track Correlation
A janky frame is a render slice, blocked on a binder call, waiting on a lock held by a thread the governor descheduled. The cause is four tracks away from the symptom.
No Shared Vocabulary
Only a couple of people on the team read a trace fluently. Which tables and tracks matter rarely leaves their head, and leaves with them.
The Real Cost of Reading Traces by Hand
- 01Hours zooming and panning a timeline to find one frame
- 02Hand-written trace_processor SQL, rebuilt from scratch each investigation
- 03Performance knowledge bottlenecked in one or two specialists
- 04Findings that live in a screenshot, not a shareable, cited report
- 05The same startup and jank triage repeated release after release
What logcat.ai Does Differently
Engine-direct reasoning over the live trace, not a flattened export
Deterministic Subsystem Profile
Twelve processors profile the trace on open: frames, startups, CPU, binder, memory, power, contention, ANRs, and more. Each returns a headline and cited findings. The deterministic floor runs before any LLM — every trace gets the same baseline.
Agentic Deep Research, in Plain English
Ask 'why did the UI jank at 4.2s?' — no SQL or schema knowledge needed. Grounded in a capability profile of your trace, the agent digs round after round against the live trace: query, read the rows, refine the hypothesis, and correlate across slices, sched, and thread_state to localize the cause. Every query it ran is auditable, and it closes by naming the concrete next angles a deeper investigation would pursue.
Charts That Build Themselves
The trace projects into a dynamic dashboard — frame timing, CPU residency, thread states, power. Deterministically generated from the trace, never hand-built. Every value traces back to a query.
Compare Traces Side by Side
Delta correlates two traces — before and after a change, fast device vs slow. Isolates which subsystem regressed. The fastest way to prove a fix actually worked.
How It Works
From a binary trace to cited findings, in one pass
Engine-direct trace analysis
Queried live over the trace, no lossy flattening
loading trace.pftrace
Watch it work on a real trace
One trace, one question. It forks four hypotheses and traces the worst frame drop through a system_server lock to a frozen app's termination.
“The UI drops a frame hard and a couple of apps stutter. What's causing the worst jank in this trace?”
The worst frame drop traces to a frozen-app termination cascade
Five performance problems surface, and the worst frame drop is a cascade. A synchronous binder call to a frozen Spotify triggered its termination, which caused a 156ms OomAdjuster lock fan-out in system_server; that lock blocked WhatsApp's main thread and produced the single worst frame drop in the trace: 150ms, 9x the 16.6ms vsync budget. Separately, YouTube's DG thread stalled 500ms on a cold-start DroidGuard binder call running 35 serialized transactions under background-GC pressure, and system_server's Wi-Fi handler serialized about 530ms of HAL calls.
The full investigation, end to end
Not a highlight. The entire deep-research run, tracing the worst frame drop back through the binder cascade.
What it finds in a real trace
A dozen processors profile the trace on open (frames, scheduling, binder, contention, power), each returning a cited finding, named to the process behind it.
WhatsApp is the dominant jank source — repeated 'App Deadline Missed' on the render path.
YouTube's main thread blocked 149 ms on a synchronous IActivityManager call.
Sustained background lock contention in system_server (ActivityManager).
Little cores (CPU0–3) spent ~63% of the trace pinned at peak frequency.
YouTube warm launch ~495 ms — narrowly inside the 500 ms budget.
Energy broadly distributed across CPU clusters, display, and modem.
No memory-pressure events — no low-memory kills in the trace.
What is a Perfetto Trace?
Perfetto is the system-wide tracing format for Android and Linux. A single capture records scheduling, frame rendering, binder IPC, locks, power rails, and app startups: every track on the device, down to the nanosecond. It is the ground truth for performance, and also the hardest artifact to read by hand.
Render timeline, jank, dropped frames
Per-CPU thread scheduling and run queues
Running, runnable, blocked, sleeping
Nested trace events on every track
CPU frequency, memory, custom metrics
Synchronous and async transaction latency
Per-rail energy on supported devices
Cold and warm app launch breakdown
Monitor contention and blocked threads
App-not-responding events and causes
You showed up with one of these
Three ways a trace lands on you, and what comes back.
Jank you can see but can't place
The app stutters and the trace is a million slices wide. The analysis above pulled the dropped frames in Slack and WhatsApp out of the noise and tied each one to the thing blocking the main thread — no manual zoom-and-hunt.
A startup or stall that's too slow
Cold start drags, a screen hangs, and "it feels slow" isn't a bug report. The investigation localizes the stall in time and names the lock, binder call, or scheduler gap behind it — cited to the slice.
A trace you need to see, not read
You captured it on a phone or an embedded target and don't want to live in the timeline. The dashboard above read this trace's structure and what was actually regressing, then built the charts that fit it: the hot subsystems, the stalls, the frames that dropped, chosen for the trace, not pre-canned.
Charts from a real trace
A sample of what comes back — built automatically from the trace, every figure tied to the slices behind it.
Real output from an actual analysis · identifiers scrubbed
Common questions
Frequently Asked Questions
Everything you need to know about Perfetto trace analysis
Standard Perfetto traces (.perfetto-trace and .pftrace) captured by on-device System Tracing, the Perfetto command-line tools, or record_android_trace. Because we read the trace directly rather than flattening it to text, anything in the Perfetto trace format (Android system traces and Linux ftrace-backed captures included) is supported.
We never flatten the trace to text. The file is opened directly as structured trace tables and queried with SQL. Deterministic processors profile frames, scheduling, binder, power, memory, startups, and contention on every trace; then an agentic investigation runs SQL across the live trace to answer your specific question, self-correcting across multiple rounds.
Jank and dropped frames with the render slice and the blocking cause, slow cold and warm startups with a phase breakdown, main-thread stalls from lock contention or binder latency, CPU contention and frequency capping, power-rail drain on supported devices, low-memory kills and memory pressure, and ANRs with the blocked thread. Findings are cited back to the slices and tracks they came from.
No. Ask questions in plain English and the agent writes the SQL for you, runs it against your trace, and explains what it found. If you do know SQL, the queries it ran are right there in the cited findings to build on.
Large multi-hundred-megabyte traces are handled by streaming the file straight into the engine rather than loading it into memory wholesale. Queries are bounded and run against the live trace, so analysis stays responsive on big captures.
Traces are encrypted in transit and at rest, and we never use your data for AI model training. Because traces are queried live in the engine rather than converted into stored, searchable chunks, the trace contents are not persisted as an index. Enterprise plans offer on-premise deployment.
Stop Living in the Timeline
Upload a trace and let logcat.ai surface the stall behind the jank