-
Notifications
You must be signed in to change notification settings - Fork 29.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
build,win,v8: allow precompiling objects-inl.h #21772
Conversation
This makes compiling v8_base much faster on Windows. Sharding is disabled because the header would have to be precompiled for each shard but is only once. The library is much smaller, so sharding is unnecessary. This is enabled by default, but disabled for CI and releases.
👍 (I was just reading a post about the improvements in PCH and was wondering how we could benefit from that :) I'm just confused about the positive/negative naming, especially Line 980 in 342dab7
IMHO if we want this to be the default, the flag should be consistently /CC @nodejs/build-files |
AFAIK we now maintain |
We own |
Sidenote: given that we own |
@jasnell We didn't do that for our other dependencies. There are no issues with |
@targos IMHO there the small issue of "implicit assumption by other collaborators" as seen above... It's not obvious who is in charge of those files... (I'll try to submit a PR for moving those, and we could discuss further) |
RE CI: linter job was stuck. Other jobs are green & other linter jobs are green. |
@refack updated to use positive naming only |
I imagine it would be very useful to have this in place before Code-and-Learn in October. @nodejs/code-and-learn |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM if CI is green
/ping @mcollina @trevnorris |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rubberstamp LGTM with green CI.
@refack Does this look OK to you? |
Maybe @digitalinfinity @kfarnung @bzoz might have opinions too. |
I don't see any issues here. ChakraCore already uses PCH on Windows, so node-chakracore can just ignore this flag. |
This makes compiling v8_base much faster on Windows. Sharding is disabled because the header would have to be precompiled for each shard but is only once. The library is much smaller, so sharding is unnecessary. This is enabled by default, but disabled for CI and releases. PR-URL: nodejs#21772 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: Kyle Farnung <kfarnung@microsoft.com> Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>
Landed in 48e5b35. |
This makes compiling v8_base much faster on Windows. Sharding is disabled because the header would have to be precompiled for each shard but is only once. The library is much smaller, so sharding is unnecessary. This is enabled by default, but disabled for CI and releases. PR-URL: #21772 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: Kyle Farnung <kfarnung@microsoft.com> Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>
This makes compiling
v8_base
much faster on Windows. On my machine, the total node build time drops from 25m29.597s to 10m58.554s.This is enabled by default when using calling
vcbuild
withoutrelease
orbuild-release
(similar toltcg
). All node tests pass, but this force-includesobjects-inl.h
in every file forv8_base
, so it is possible that this causes subtle issues and is thus disabled in CI and for releases. This includes onlyobjects-inl.h
to minimize the chance for issues, it is already included in many files. Adding other headers only improves the build time in the order of seconds.Sharding is disabled because the header would have to be precompiled for each shard but is only once. The library is much smaller, so sharding is not necessary with this either way.
Can the changes in
v8.gyp
be floated on top of V8 updates, or does this need to be submitted upstream? Are we maintaining the gyp files? (cc @nodejs/v8-update)cc @nodejs/platform-windows
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes