Skip to content

CONCEPT Cited by 1 source

Chrome Trace Event Format

Definition

Chrome Trace Event Format (often just "Trace Event Format") is Chromium's JSON-based trace-file format, originally documented here. A trace file is a JSON array (or wrapped-object form) of trace events with fields like:

  • name — event name (often a function / span name)
  • cat — category (often a module / subsystem)
  • ph — phase: B/E (duration-begin/end), X (complete), i (instant), b/e (async-begin/end), M (metadata)
  • ts — microsecond timestamp
  • pid, tid — process + thread ID
  • args — arbitrary key/value payload
  • id — async-event flow id

Consumers

  • Perfetto (ui.perfetto.dev) — the primary modern consumer UI.
  • Chrome's chrome://tracing — the historical consumer, superseded by Perfetto.
  • Go's go tool trace — consumes Go runtime traces in a compatible extended format.
  • Rust's tracing-chrome crate — emits this format from the tracing ecosystem.
  • Node.js node --prof-process --preprocess -j … + downstream converters.

Turborepo's --profile flag writes a Chrome Trace Event Format JSON consumable by Perfetto.

Format pathologies for agent consumption

In 2026-04-21 Vercel Turborepo performance post, Anthony Shew documents the specific ways Chrome Trace Event JSON hurts LLM-based agent reasoning about hotspots:

  • Function identifiers split across lines. Long fully- qualified names (e.g. Rust's monomorphised generics) break across many physical lines in a pretty-printed JSON.
  • Irrelevant metadata interleaved with timing data. .file, .line, pid, tid, cat fields on every event clutter the signal (function name + self-time) the agent actually needs.
  • Not grep-friendly. The information an agent wants (e.g. "which function has the highest self-time") is not on a single line; grep doesn't recover it.
  • Single-letter keys (ph, ts) are information- dense for the UI's parser but opaque to an agent reasoning about the trace.

The canonical verbatim framing:

"An LLM can theoretically read through and parse all this, but...well...just look at it. Function identifiers split across lines, irrelevant metadata mixed in with timing data, not grep-friendly. I pointed an agent at the file and watched it struggle through grep calls, trying to piece together function names from different lines, unsuccessfully trying to filter out noise."

Resolution

The format isn't wrong — it's optimised for UI parsers that need all fields, not for agent reasoning. The canonical fix is the Markdown profile output pattern: emit both JSON (for Perfetto) and .md (for agents) from the same underlying span data. See concepts/markdown-as-agent-friendly-format.

Canonical event shape

Abbreviated sample from a Turborepo profile:

{"ph":"M","pid":1,"name":"process_name","args":{"name":"turbo 2.8.21-canary.9"}}
{"ph":"M","pid":1,"name":"process_labels","args":{"labels":"macos, 14 CPUs"}}
{"ph":"M","pid":1,"name":"thread_name","tid":0,"args":{"name":"main"}}
{"ph":"b","pid":1,"ts":52.917,"name":"shim_run","cat":"turborepo_lib::shim","tid":0,"id":2251799813685249,".file":"crates/turborepo-lib/src/shim.rs",".line":224}

Seen in

Last updated · 476 distilled / 1,218 read