mirror of
https://github.com/hanzoai/next.js.git
synced 2026-10-30 14:46:38 +00:00
Marcos HernanzandGitHub
6c5e0bbd74
## Summary - skip the redundant aggregation-root update when `ConnectChildOperation` reconnects an already constructed top-level task that is already an aggregation root - avoid entering the aggregation operation loop when no update was queued The fast path is intentionally narrow. It applies only when the connection has no parent, the task has materialized output, and the task's aggregation number is already the root sentinel. The task may still be dirty and need to run; this only skips an idempotent aggregation update. A task that is not yet a root still goes through the normal update on its first top-level connection. Tasks without output are still scheduled, parented connections retain their activeness and aggregation updates, and transient-state boundaries are unchanged. ## Findings The earlier scheduler experiment has been removed completely. The apparent benefit from keeping a worker alive with `std::thread::yield_now()` was specific to the benchmark topology: Criterion's `Runtime::block_on` caller runs outside the single-worker Tokio runtime, so that external caller can enqueue the next root task while the runtime worker is yielding at the OS level. The sole Tokio worker itself cannot produce work during that loop. In normal scheduling, tasks typically enqueue their children before the current job exits, and a multi-worker runtime can start another worker when it is below its target. That does not justify burning CPU in an idle worker, nor replacing the loop with an async-yield retry loop. The retained optimization is independent of that artifact. An already constructed top-level task that is already rooted has no new root update to perform; re-enqueuing the idempotent update only forces the operation executor through unnecessary suspend points. This PR now contains no changes to `priority_runner`, worker lifetime, busy waiting, OS-thread yielding, async yielding, HMR, filesystem watching, or documentation. ## Benchmark results The benchmark source, runtime construction, profiles, allocator, toolchain, and worker count were unchanged. Frozen baseline and candidate executables were run adjacently in alternating order. Three focused pairs met the control-drift threshold; one pair was excluded before analysis because its Tokio control moved by more than 2%. Median candidate changes across the valid pairs: | Case | Change | | --- | ---: | | direct control | +0.071% | | Tokio control | -0.177% | | uncached task | +1.266% | | cached, same key | -37.868% | | cached, different keys | -26.783% | The complete all-duration local sweeps did not meet the control thresholds, so their task measurements are deliberately not cited. Fresh remote CodeSpeed and Stats results are the authoritative guardrail for the full benchmark. ## Verification - `cargo fmt --all -- --check` - `cargo clippy -p turbo-tasks-backend --all-targets -- -D warnings -A deprecated` - `cargo test -p turbo-tasks-backend` - `pnpm build-all` - two-engine autoreview after the final changes, with no findings - Not run: `pnpm --filter=next dev` (the final diff is Rust-only and was covered by the full bootstrap build and Cargo suites)