-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
src: cache the result of GetOptions() in JS land #24091
Conversation
Instead of calling into C++ each time we need to check the value of a command line option, cache the option map in a new `internal/options` module for faster access to the values in JS land.
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 with 1 comment
@@ -211,8 +211,7 @@ | |||
|
|||
NativeModule.isInternal = function(id) { | |||
return id.startsWith('internal/') || | |||
(id === 'worker_threads' && | |||
!internalBinding('options').getOptions('--experimental-worker')); | |||
(id === 'worker_threads' && !config.experimentalWorker); |
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.
Can we avoid going back to process.config
? 😕
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.
There are also two other reference to config
in here, I think a better option would probably be to just specialize something for NativeModule here - maybe just directly generate the whole map when the process starts and pass it to the loader bootstrapper here and let NativeModule short-circuit the internal/options
implementation. That also opens up the opportunity to emit all the warning for experimental modules in one place here instead of emitting them everywhere across the code base.
EDIT: wait, we emit them regardless of the cli options..so never mind I guess
Fixed linter and the bootstrap module list test: https://ci.nodejs.org/job/node-test-pull-request/18336/ |
I get that motivation, but couldn't we make it simpler? I'd be happy to share your reasoning. |
@refack See #24091 (comment) my reasoning is we could just eliminate calling into C++ at all eventually by creating the map before bootstrapping loaders so it will be made available in loafers.js as an argument directly. This PR just moves the calls to a central place that can be manipulated in loaders.js |
Resume: https://ci.nodejs.org/job/node-test-commit/22901/ |
@refack Just to explore about this point a bit further - I think the reason why |
Main reason sure, but it's also been quoted as a braier for adding new (trivial) modules - #23081 (review) Again, I'm slightly in favor... Encapsulation/Performance is just a balance we should keep in mind. |
ubuntu-on-arm had a flake, so resume again: https://ci.nodejs.org/job/node-test-commit/22902/ |
Instead of calling into C++ each time we need to check the value of a command line option, cache the option map in a new `internal/options` module for faster access to the values in JS land. PR-URL: nodejs#24091 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Refael Ackermann <refack@gmail.com>
Landed in f895b5a |
Instead of calling into C++ each time we need to check the value of a command line option, cache the option map in a new `internal/options` module for faster access to the values in JS land. PR-URL: #24091 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Refael Ackermann <refack@gmail.com>
Instead of calling into C++ each time we need to check the value of a command line option, cache the option map in a new `internal/options` module for faster access to the values in JS land. PR-URL: nodejs#24091 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Refael Ackermann <refack@gmail.com>
Instead of calling into C++ each time we need to check the value of a command line option, cache the option map in a new `internal/options` module for faster access to the values in JS land. PR-URL: #24091 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Refael Ackermann <refack@gmail.com>
Instead of calling into C++ each time we need to check the value of a command line option, cache the option map in a new `internal/options` module for faster access to the values in JS land. PR-URL: #24091 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Refael Ackermann <refack@gmail.com>
Instead of calling into C++ each time we need to check the value of a command line option, cache the option map in a new `internal/options` module for faster access to the values in JS land. PR-URL: #24091 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Refael Ackermann <refack@gmail.com>
Instead of calling into C++ each time we need to check the value
of a command line option, cache the option map in a new
internal/options
module for faster access to the values in JS land.