next.js

8cbab6e6 - Perf: Fast path for trace() when opentelemetry is not enabled (#92678)

Perf: Fast path for trace() when opentelemetry is not enabled (#92678) ### 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, and `context.with(...)` setup. That adds avoidable overhead for the default no-op tracing case. ### How? - add an `isTracingEnabled()` check that treats an active recording span as enabled - detect the default `ProxyTracerProvider -> NoopTracerProvider` setup and treat it as tracing disabled - bail out of `trace()` before any span or context work when neither tracing nor performance logging is enabled # Benchmark ## Setup - Scenario: `e2e` (next build + next start, Turbopack) - Stream mode: `node` - Route: `/` (lightest route, most sensitive to per-request overhead) - Serial requests: 500, load requests: 5000, load concurrency: 80 ## Single-client (req/s) | | Run 1 | Run 2 | Run 3 | Avg | | --- | --- | --- | --- | --- | | Canary | 743 | 755 | 789 | **762** | | PR #92678 | 785 | 787 | 837 | **803** | | **Delta** | | | | **+5.4%** | ## Under-load (req/s) | | Run 1 | Run 2 | Run 3 | Avg | | --- | --- | --- | --- | --- | | Canary | 1689 | 1768 | 1852 | **1770** | | PR #92678 | 1799 | 1926 | 1767 | **1831** | | **Delta** | | | | **+3.4%** | ## 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. <!-- NEXT_JS_LLM_PR -->