Add trace spans for turbopack persistence in .next/trace#90397
Add trace spans for turbopack persistence in .next/trace#90397lukesandberg merged 4 commits intocanaryfrom
Conversation
Tests Passed |
Stats from current PR✅ No significant changes detected📊 All Metrics📖 Metrics GlossaryDev Server Metrics:
Build Metrics:
Change Thresholds:
⚡ Dev Server
📦 Dev Server (Webpack) (Legacy)📦 Dev Server (Webpack)
⚡ Production Builds
📦 Production Builds (Webpack) (Legacy)📦 Production Builds (Webpack)
📦 Bundle SizesBundle Sizes⚡ TurbopackClient Main Bundles: **401 kB** → **401 kB** ✅ -31 B80 files with content-based hashes (individual files not comparable between builds) Server Middleware
Build DetailsBuild Manifests
📦 WebpackClient Main Bundles
Polyfills
Pages
Server Edge SSR
Middleware
Build DetailsBuild Manifests
Build Cache
🔄 Shared (bundler-independent)Runtimes
📎 Tarball URL |
Merging this PR will degrade performance by 3.48%
Performance Changes
Comparing Footnotes
|
| } | ||
|
|
||
| // Record TraceEvent compilation events as trace spans in .next/trace. | ||
| if (parentSpan && event.typeName === 'TraceEvent' && event.eventJson) { |
There was a problem hiding this comment.
ideally eventJson would also be a napi_object so we could get types generated
There was a problem hiding this comment.
I think this is a crate hierarchy problem, not really a napi problem. TraceEvent is defined in turbo-tasks, but we don't want that crate to depend on napi.
There was a problem hiding this comment.
correct, i would need to create a dual set of types in the next crate that is emitting these events and then we could get types..
this works but is officially lame
0642539 to
733a839
Compare
733a839 to
42d0e06
Compare
wbinnssmith
left a comment
There was a problem hiding this comment.
lgtm. thanks for cleaning up the reporters!
42d0e06 to
e19727d
Compare
Merge activity
|
## Summary - Add a generic `TraceEvent` compilation event type that carries a name, wall-clock timing, and arbitrary attributes - Emit `TraceEvent` from Turbopack's Rust backend for cache persistence and compaction operations - Expose `eventJson` on compilation events through the NAPI bridge - Record `turbopack-persistence` and `turbopack-compaction` trace spans in `.next/trace` with memory usage snapshots, in both dev and build workflows ## Details Turbopack persistence and compaction operations were invisible in `.next/trace`. The only signal was a console log for operations exceeding 10s. A new generic `TraceEvent` type replaces the need for per-operation event structs. It carries a name, start/end wall-clock timestamps, and a `Vec` of key-value attributes. On the JS side, `backgroundLogCompilationEvents` handles all `TraceEvent`s with a single code path — creating trace spans via `manualTraceChild` and recording memory usage snapshots. Adding new traced operations requires only a few lines of Rust and zero JS changes. At @bgw's suggestion, I considered integrating as a `tracing_subscriber::Layer` to automatically forward spans to the compilation event system, but this ended up requiring quite a bit of code (a new subscriber, 'target' impl, span lifecycle management, new crate dependencies) for what is currently just 2 events, and we don't really anticipate adding more. ## Test plan - [x] Integration test in `test/e2e/filesystem-cache` verifying `turbopack-persistence` spans exist with correct attributes - [x] `pnpm test-dev-turbo test/e2e/filesystem-cache` - [x] `pnpm test-start-turbo test/e2e/filesystem-cache`

Summary
TraceEventcompilation event type that carries a name, wall-clock timing, and arbitrary attributesTraceEventfrom Turbopack's Rust backend for cache persistence and compaction operationseventJsonon compilation events through the NAPI bridgeturbopack-persistenceandturbopack-compactiontrace spans in.next/tracewith memory usage snapshots, in both dev and build workflowsDetails
Turbopack persistence and compaction operations were invisible in
.next/trace. The only signal was a console log for operations exceeding 10s.A new generic
TraceEventtype replaces the need for per-operation event structs. It carries a name, start/end wall-clock timestamps, and aVecof key-value attributes. On the JS side,backgroundLogCompilationEventshandles allTraceEvents with a single code path — creating trace spans viamanualTraceChildand recording memory usage snapshots. Adding new traced operations requires only a few lines of Rust and zero JS changes.At @bgw's suggestion, I considered integrating as a
tracing_subscriber::Layerto automatically forward spans to the compilation event system, but this ended up requiring quite a bit of code (a new subscriber, 'target' impl, span lifecycle management, new crate dependencies) for what is currently just 2 events, and we don't really anticipate adding more.Test plan
test/e2e/filesystem-cacheverifyingturbopack-persistencespans exist with correct attributespnpm test-dev-turbo test/e2e/filesystem-cachepnpm test-start-turbo test/e2e/filesystem-cache