Repository navigation
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
4 tasks done
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## refactor/html-all #1243 +/- ##
==================================================
Coverage 94.55% 94.55%
==================================================
Files 297 297
Lines 31220 31221 +1
Branches 3187 3187
==================================================
+ Hits 29521 29522 +1
Misses 1677 1677
Partials 22 22 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
🚀 Deploying Preview to Cloudflare 🚀Preview Deployments by commit
View all previews: View all previews ↗ |
avivkeller
approved these changes
Nov 3, 2026
ovflowd
marked this pull request as ready for review
November 3, 2026 20:39
ovflowd
force-pushed
the
perf/six-threads
branch
from
November 4, 2026 18:24
f1082fe to
4d830af
Compare
ovflowd
force-pushed
the
perf/six-threads
branch
from
November 6, 2026 13:37
4d830af to
7e715a5
Compare
2 of 4 tasks
ovflowd
force-pushed
the
perf/six-threads
branch
from
November 6, 2026 19:31
7e715a5 to
c97afb1
Compare
ovflowd
force-pushed
the
perf/six-threads
branch
from
November 6, 2026 19:43
c97afb1 to
cf7e6c8
Compare
avivkeller
force-pushed
the
perf/six-threads
branch
from
November 9, 2026 02:26
cf7e6c8 to
fd18bd4
Compare
ovflowd
force-pushed
the
perf/six-threads
branch
from
November 9, 2026 10:37
fd18bd4 to
5624386
Compare
ovflowd
force-pushed
the
perf/six-threads
branch
from
November 9, 2026 11:03
5624386 to
c4b0dc4
Compare
ovflowd
force-pushed
the
perf/six-threads
branch
from
November 9, 2026 13:25
c4b0dc4 to
d6f41cc
Compare
This was referenced Nov 9, 2026
ovflowd
force-pushed
the
perf/six-threads
branch
from
November 10, 2026 20:53
d6f41cc to
c283664
Compare
With generators streaming into each other, more threads now pay off, so DEFAULT_MAX_THREADS goes from 4 to 6. On the Node.js API docs the site build is ~15% faster at 6 threads than at 4, for ~20% more memory; 8 threads were no faster than 6 and used ~15% more. Machines with fewer CPUs, like CI's 4, are unaffected, and --threads still sets any count. Assisted-by: Claude Opus 5.5 <noreply@anthropic.com> Assisted-by: Claude Sonnet 5.5 <noreply@anthropic.com>
ovflowd
force-pushed
the
perf/six-threads
branch
from
November 11, 2026 00:07
c283664 to
589914f
Compare
This branch was successfully deployed
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 join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Description
This PR makes builds use up to 6 threads by default, instead of 4. It's the last part of the stack that splits #1205. On top of the stack, the site build goes from 8.09s at 4 threads to 7.09s at 6, against 9.82s for
mainat 4.8 threads were no faster than 6 for the site build on Node.js 24, and used ~15% more memory; I haven't re-measured them on Node.js 26. Machines with fewer CPUs, like CI's 4, are unaffected, and
--threadsstill sets any count.Why it's built this way
Isn't the stack's speedup just the extra threads? No. At the same thread count, #1242 is 18% faster than
mainat 4 threads and 17% faster at 6. Going from 4 to 6 threads is a separate gain, andmaingets about the same from it (-13%, against -12% on #1242). So 6 threads would have paid off before the stack too. What kept the default at 4 is memory, since each worker holds a heap of its own.What does it cost? On #1242 the two extra threads add 655MB to the site build's peak, against 552MB on
mainin the same run, and 393MB to legacy. Each at its own default, measured in one round before the manifest fix in #1241, this branch againstmainis -22% time and +52% memory on the site build, and -10% / +28% on legacy. Most of that memory comes back with #1235 and #1236: with them, againstmainbefore #1237, each at its own default, the site build is 29% faster for 24% more memory (measured before the manifest fix in #1241, which moves the 6-thread peak by ~3%).--threads 4gets the old behaviour back, each worker's heap is still capped at 512MB, and-p 1isn't touched.Why does the bundler get 6 too? Since #1179, Vite's native pools (rolldown and lightningcss) follow doc-kit's thread count through
ROLLDOWN_WORKER_THREADSandRAYON_NUM_THREADS. Otherwise they'd start a thread per CPU, 32 on this machine. This PR only moves the number they follow, and the numbers below include the bundler at 6. Keeping it at 4 while the workers go to 6 would be a second knob I haven't measured. Either variable set in the environment still wins.What about CI? The default is
Math.min(cpus().length, 6). CI'subuntu-latestrunners have 4 CPUs, so CI keeps 4 workers and a 4-thread bundler, and the time and RSS in its comparison comment stay comparable withmain's. riscv64 stays at 1, and #1253 runs withthreads: 1, so it doesn't exercise this change.Benchmarks
Full Node.js docs on Node.js 26, 32 CPUs, medians of 5 interleaved runs, peak RSS summed over the process tree. The site build is
orama-db,json,llms-txtandsection-pages, plushtml-allfrom #1242 on (onmain,htmlstill buildsall.htmlitself). Each row is one build at-p 4and-p 6, so the columns differ only by the thread count, which is all this PR changes:-p 4-p 6mainThe first two rows are one run, with the manifest fix that #1241 now includes. Legacy doesn't go through
jsx-ast, so the fix doesn't touch it; that row and the last one come from earlier runs, from before the fix.Everything merged, after the review fixes
The stack with #1235 and #1236 on top, before the review fixes (tests trimmed,
createSignalinlined,discardResults, html-all's dead fallback gone) and after, againstmain. One round, medians of 5 interleaved runs (3 at-p 1). This machine ran slower overall in this round, so compare the columns with each other, not with the tables above:mainThe fixes don't move it. The
-p 1memory gap between before and after is GC timing: per-run peaks overlap (site 1651-1783MB before, 1592-1792MB after).Validation
The benchmarks above, plus
-p 1with--max-old-space-size=512, 3 runs each: the site build passed all 11 at ~1000MB peak RSS (mainhit V8's out-of-memory abort in 1 of 8 runs), and legacy passed all 3 at 877MB.Related Issues
Refs: #1205, and nodejs/nodejs.org#9253, which caches tokens for both themes and makes the site build faster still.
Check List
node --run testand all tests passed.node --run format:check&node --run lint.