Perf: Fast path for trace() when opentelemetry is not enabled#92678
Merged
timneutkens merged 1 commit intoApr 15, 2026
Merged
Conversation
nextjs-bot
added
created-by: Turbopack team
timneutkens
changed the title
timneutkens
changed the title
Contributor
Tests Passed |
timneutkens
added a commit
that referenced
this pull request
Apr 13, 2026
## What Adds a new "A/B branch comparison" section to `bench/BENCHMARKING.md` with practical guidance for comparing benchmark results across two branches. ## Why From running benchmarks comparing canary vs PR #92678, we identified several patterns that lead to noisy or misleading results: - Running the full route suite when only one route shows signal wastes time (~3 min per run) - The default 120 serial requests is too noisy for sub-2ms routes - Single runs can swing 10-15% on light routes - Percentage deltas from a single pair of runs can be misleading without absolute numbers ## What's in the new section - Start with a focused route, not the full suite - Increase request counts for fast routes (500 serial / 5000 load) - Run at least 3 times per side to average out noise - Compare absolute req/s, not just deltas - Watch for system state drift between runs - Full example workflow with checkout/build/run loop <!-- NEXT_JS_LLM_PR -->
gnoff
approved these changes
Apr 14, 2026
timneutkens
deleted the
03-13-perf_only_instrument_clientcomponentloadtimes_when_used
branch
This was referenced Apr 23, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What?
Skip the
tracer.trace()instrumentation path when OpenTelemetry tracing is not actually enabled.Why?
trace()is used in hot paths, and even with tracing disabled it was still doing option coercion, context lookups, span bookkeeping, andcontext.with(...)setup. That adds avoidable overhead for the default no-op tracing case.How?
isTracingEnabled()check that treats an active recording span as enabledProxyTracerProvider -> NoopTracerProvidersetup and treat it as tracing disabledtrace()before any span or context work when neither tracing nor performance logging is enabledBenchmark
Setup
e2e(next build + next start, Turbopack)node/(lightest route, most sensitive to per-request overhead)Single-client (req/s)
Under-load (req/s)
Conclusion
The PR shows a consistent ~5% req/s improvement on single-client
/across 3 runs, where the tracer overhead is proportionally largest relative to render time. Streaming-heavy routes are unaffected since render time dominates. Under-load shows a smaller +3.4% improvement with more variance.