process: js fast path for cached bindings by apapirovski · Pull Request #18365 · nodejs/node

apapirovski · 2018-01-25T04:34:44Z

Currently, both process.binding and internalBinding have to call into C++ regardless of whether the module has been cached or not. This creates significant overhead to all binding calls and unfortunately the rest of the codebase doesn't really optimize the amount of times that bindings are required (as an example: 12 files require the async_wrap binding).

Changing all the usage of this function throughout the codebase would introduce a lot of churn (and is kind of a hassle) so instead this PR introduces a JS fast path for both functions for cases where the binding has already been cached. While micro benchmarks are not super meaningful here (it's not like we call binding that often...), this does speed up the cached call by 400%.

Checklist

make -j4 test (UNIX), or vcbuild test (Windows) passes
commit message follows commit guidelines

Affected core subsystem(s)

process, src

apapirovski · 2018-01-25T04:36:15Z

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

TimothyGu

Rest LGTM

TimothyGu · 2018-01-25T04:54:24Z

lib/internal/bootstrap_node.js

+
+    process.binding = function binding(module) {
+      if (!module || typeof module !== 'string')
+        return;


It’s unfortunate, but process.binding is used in the wild too often for us to be able to just return undefined if the requested module is undefined. We should cast it to a string just as the C++ version did.

Also, when would core code call it with something that is not a string? This guard should probably just go.

bnoordhuis

If you're adding caching in JS land, then I'd get rid of env->binding_cache_object() +env->internal_binding_cache_object() and strip down node::Binding() and node::InternalBinding() to their bare essentials.

bnoordhuis · 2018-01-25T10:46:56Z

lib/internal/bootstrap_node.js

+
+    process.binding = function binding(module) {
+      if (!module || typeof module !== 'string')
+        return;


Also, when would core code call it with something that is not a string? This guard should probably just go.

apapirovski · 2018-01-25T13:50:58Z

@TimothyGu @bnoordhuis Thanks for the feedback. I've updated the PR based on your suggestions.

bnoordhuis

LGTM modulo comment. Binding() and InternalBinding() have quite some shared logic you could factor out.

bnoordhuis · 2018-01-25T14:49:49Z

lib/internal/bootstrap_node.js

+      if (typeof bindingObj[module] === 'object')
+        return bindingObj[module];
+      bindingObj[module] = getLinkedBinding(module);
+      return bindingObj[module];


Minor anti-pattern, looking up twice. Do this instead:

let mod = bindingObj[module]; if (typeof mod !== 'object') mod = bindingObj[module] = getBinding(module); return mod;

Good catch, don't know what I was thinking :) Updated.

apapirovski · 2018-01-25T15:42:10Z

Ok, I've added one final change in terms of moving process.moduleLoadList to JS-land. I'll leave refactoring C++ Binding & InternalBinding for someone else and/or another PR.

bnoordhuis

Looks nice.

apapirovski · 2018-01-25T15:58:12Z

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

joyeecheung

Nice, this also gives me a good idea where to monkey-patch the deprecate bindings....

Fishrock123

Nice catch.

apapirovski · 2018-01-29T16:56:46Z

Landed in bb27bfe

Currently, both process.binding and internalBinding have to call into C++ regardless of whether the module has been cached or not. This creates significant overhead to all binding calls and unfortunately the rest of the codebase doesn't really optimize the amount of times that bindings are required (as an example: 12 files require the async_wrap binding). Changing all the usage of this function throughout the codebase would introduce a lot of churn (and is kind of a hassle) so instead this PR introduces a JS fast path for both functions for cases where the binding has already been cached. While micro benchmarks are not super meaningful here (it's not like we call binding that often...), this does speed up the cached call by 400%. In addition, move moduleLoadList creation and management entirely into JS-land as it requires less code and is more efficient. PR-URL: #18365 Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>

MylesBorins · 2018-02-27T07:12:35Z

Does this make sense for LTS?

joyeecheung · 2018-03-15T17:00:50Z

@MylesBorins I think it makes sense to backport this to v8.x, I am trying to backport #19112 to v8.x but a test fails because it depends on this to get a complete fix. @apapirovski are you working on a backport? I can help backporting this one in order to get #19112 backported.

Currently, both process.binding and internalBinding have to call into C++ regardless of whether the module has been cached or not. This creates significant overhead to all binding calls and unfortunately the rest of the codebase doesn't really optimize the amount of times that bindings are required (as an example: 12 files require the async_wrap binding). Changing all the usage of this function throughout the codebase would introduce a lot of churn (and is kind of a hassle) so instead this PR introduces a JS fast path for both functions for cases where the binding has already been cached. While micro benchmarks are not super meaningful here (it's not like we call binding that often...), this does speed up the cached call by 400%. In addition, move moduleLoadList creation and management entirely into JS-land as it requires less code and is more efficient. PR-URL: nodejs#18365 Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>

MylesBorins · 2018-03-20T15:29:26Z

@joyeecheung if you could backport to 8.x that would be great. should we set dont-land-v6.x?

Currently, both process.binding and internalBinding have to call into C++ regardless of whether the module has been cached or not. This creates significant overhead to all binding calls and unfortunately the rest of the codebase doesn't really optimize the amount of times that bindings are required (as an example: 12 files require the async_wrap binding). Changing all the usage of this function throughout the codebase would introduce a lot of churn (and is kind of a hassle) so instead this PR introduces a JS fast path for both functions for cases where the binding has already been cached. While micro benchmarks are not super meaningful here (it's not like we call binding that often...), this does speed up the cached call by 400%. In addition, move moduleLoadList creation and management entirely into JS-land as it requires less code and is more efficient. PR-URL: nodejs#18365 Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>

MylesBorins · 2018-05-23T18:00:57Z

ping @joyeecheung regarding a 8.x backport

should include #19112 and #19117

Currently, both process.binding and internalBinding have to call into C++ regardless of whether the module has been cached or not. This creates significant overhead to all binding calls and unfortunately the rest of the codebase doesn't really optimize the amount of times that bindings are required (as an example: 12 files require the async_wrap binding). Changing all the usage of this function throughout the codebase would introduce a lot of churn (and is kind of a hassle) so instead this PR introduces a JS fast path for both functions for cases where the binding has already been cached. While micro benchmarks are not super meaningful here (it's not like we call binding that often...), this does speed up the cached call by 400%. In addition, move moduleLoadList creation and management entirely into JS-land as it requires less code and is more efficient. PR-URL: nodejs#18365 Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>

process: js fast path for cached bindings

56db1ab

nodejs-github-bot added c++ Issues and PRs that require attention from people who are familiar with C++. lib / src Issues and PRs related to general changes in the lib or src directory. labels Jan 25, 2018

TimothyGu approved these changes Jan 25, 2018

View reviewed changes

bnoordhuis reviewed Jan 25, 2018

View reviewed changes

fixup: move the full caching functionality to JS

753a081

bnoordhuis approved these changes Jan 25, 2018

View reviewed changes

apapirovski added 2 commits January 25, 2018 10:03

fixup: bnoordhuis comment

b5fb9c1

process: move moduleLoadList definition & usage to JS

ea60d2c

apapirovski force-pushed the patch-binding-fast-path-js branch from f45097e to ea60d2c Compare January 25, 2018 15:39

bnoordhuis approved these changes Jan 25, 2018

View reviewed changes

joyeecheung approved these changes Jan 25, 2018

View reviewed changes

addaleax approved these changes Jan 25, 2018

View reviewed changes

jasnell approved these changes Jan 26, 2018

View reviewed changes

Fishrock123 approved these changes Jan 26, 2018

View reviewed changes

maclover7 force-pushed the master branch from bb5575a to 993b716 Compare January 26, 2018 22:03

cjihrig force-pushed the master branch from 993b716 to 082f952 Compare January 26, 2018 22:36

apapirovski closed this Jan 29, 2018

apapirovski deleted the patch-binding-fast-path-js branch January 29, 2018 16:56

evanlucas mentioned this pull request Jan 30, 2018

v9.5.0 release proposal #18464

Merged

MylesBorins added lts-watch-v6.x labels Feb 27, 2018

MylesBorins added backport-requested-v8.x and removed lts-watch-v6.x labels May 23, 2018

MylesBorins mentioned this pull request May 23, 2018

src: bootstrap internals loaders before bootstrapping Node.js #19112

Closed

2 tasks

Uh oh!

Conversation

apapirovski commented Jan 25, 2018

Checklist

Affected core subsystem(s)

Uh oh!

apapirovski commented Jan 25, 2018

Uh oh!

TimothyGu left a comment

Choose a reason for hiding this comment

Uh oh!

TimothyGu Jan 25, 2018

Choose a reason for hiding this comment

Uh oh!

bnoordhuis Jan 25, 2018

Choose a reason for hiding this comment

Uh oh!

bnoordhuis left a comment

Choose a reason for hiding this comment

Uh oh!

bnoordhuis Jan 25, 2018

Choose a reason for hiding this comment

Uh oh!

apapirovski commented Jan 25, 2018

Uh oh!

bnoordhuis left a comment

Choose a reason for hiding this comment

Uh oh!

bnoordhuis Jan 25, 2018

Choose a reason for hiding this comment

Uh oh!

apapirovski Jan 25, 2018

Choose a reason for hiding this comment

Uh oh!

apapirovski commented Jan 25, 2018

Uh oh!

bnoordhuis left a comment

Choose a reason for hiding this comment

Uh oh!

apapirovski commented Jan 25, 2018

Uh oh!

joyeecheung left a comment

Choose a reason for hiding this comment

Uh oh!

Fishrock123 left a comment

Choose a reason for hiding this comment

Uh oh!

apapirovski commented Jan 29, 2018

Uh oh!

MylesBorins commented Feb 27, 2018

Uh oh!

joyeecheung commented Mar 15, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

MylesBorins commented Mar 20, 2018

Uh oh!

MylesBorins commented May 23, 2018

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

joyeecheung commented Mar 15, 2018 •

edited

Loading