build,win,v8: allow precompiling objects-inl.h

[joaocgreis]

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 without release or build-release (similar to ltcg). All node tests pass, but this force-includes objects-inl.h in every file for v8_base, so it is possible that this causes subtle issues and is thus disabled in CI and for releases. This includes only objects-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), or vcbuild test (Windows) passes
• commit message follows commit guidelines

[nodejs-github-bot]

@joaocgreis build started: https://ci.nodejs.org/blue/organizations/jenkins/node-test-pull-request-lite-pipeline/detail/node-test-pull-request-lite-pipeline/254/pipeline

[joaocgreis]

CI: https://ci.nodejs.org/view/All/job/node-test-pull-request/15815/

[refack]

👍 (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

node/configure

Line 980 in 342dab7

o['variables']['node_use_pch'] = b(not options.without_pch)

IMHO if we want this to be the default, the flag should be consistently without for opt-out. If we want this to be a dev-only optimization, then it should be consistently with for opt-in.

/CC @nodejs/build-files

[refack]

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?

AFAIK we now maintain deps/v8/gypfiles. But if this has such a benefit on compile time, maybe this could be submitted upstream as a whole?

[targos]

We own deps/v8/gypfiles. The change wouldn't need to be floated.

[jasnell]

Sidenote: given that we own deps/v8/gypfiles, would it make more sense / be cleaner for us to move those out of the deps folder?

[targos]

@jasnell We didn't do that for our other dependencies. There are no issues with deps/v8/gypfiles from my perspective.

[refack]

There are no issues with deps/v8/gypfiles from my perspective.

@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)

[refack]

RE CI: linter job was stuck. Other jobs are green & other linter jobs are green.

[joaocgreis]

@refack updated to use positive naming only

[Trott]

CI: https://ci.nodejs.org/job/node-test-pull-request/15998/

[Trott]

I imagine it would be very useful to have this in place before Code-and-Learn in October. @nodejs/code-and-learn

[Trott]

LGTM if CI is green

[Trott]

/ping @mcollina@trevnorris

[mcollina]

Rubberstamp LGTM with green CI.

[Trott]

@refack Does this look OK to you?

[Trott]

Maybe @digitalinfinity@kfarnung@bzoz might have opinions too.

[kfarnung]

I don't see any issues here. ChakraCore already uses PCH on Windows, so node-chakracore can just ignore this flag.

[Trott]

Landed in 48e5b35.