src,lib: reducing C++ calls of esm legacy main resolve by H4ad · Pull Request #48325 · nodejs/node · GitHub

This PR is related to nodejs/performance#73

Legacy Main Resolve

@anonrig raised that we could benefit from the implementation of legacyMainResolve on the C++ side, so here's the result so far:

                                                                                                                                                                confidence improvement accuracy (*)
esm/esm-legacyMainResolve.js resolvedFile='node_modules/non-exist' packageConfigMain='./index.js' packageJsonUrl='node_modules/test/package.json' n=10000              ***     34.86 %       ±1.41%
esm/esm-legacyMainResolve.js resolvedFile='node_modules/non-exist' packageConfigMain='' packageJsonUrl='node_modules/test/package.json' n=10000                        ***     34.92 %       ±1.52%
esm/esm-legacyMainResolve.js resolvedFile='node_modules/test/index.js' packageConfigMain='./index.js' packageJsonUrl='node_modules/test/package.json' n=10000          ***     34.53 %       ±1.22%
esm/esm-legacyMainResolve.js resolvedFile='node_modules/test/index.js' packageConfigMain='' packageJsonUrl='node_modules/test/package.json' n=10000                    ***     35.39 %       ±1.57%
esm/esm-legacyMainResolve.js resolvedFile='node_modules/test/index.json' packageConfigMain='./index.js' packageJsonUrl='node_modules/test/package.json' n=10000        ***     34.78 %       ±1.30%
esm/esm-legacyMainResolve.js resolvedFile='node_modules/test/index.json' packageConfigMain='' packageJsonUrl='node_modules/test/package.json' n=10000                  ***     35.39 %       ±1.15%
esm/esm-legacyMainResolve.js resolvedFile='node_modules/test/index.node' packageConfigMain='./index.js' packageJsonUrl='node_modules/test/package.json' n=10000        ***     34.75 %       ±1.43%
esm/esm-legacyMainResolve.js resolvedFile='node_modules/test/index.node' packageConfigMain='' packageJsonUrl='node_modules/test/package.json' n=10000                  ***     35.84 %       ±1.33%
                                                                                                                                                                  (**)  (***)
esm/esm-legacyMainResolve.js resolvedFile='node_modules/non-exist' packageConfigMain='./index.js' packageJsonUrl='node_modules/test/package.json' n=10000       ±1.88% ±2.45%
esm/esm-legacyMainResolve.js resolvedFile='node_modules/non-exist' packageConfigMain='' packageJsonUrl='node_modules/test/package.json' n=10000                 ±2.02% ±2.64%
esm/esm-legacyMainResolve.js resolvedFile='node_modules/test/index.js' packageConfigMain='./index.js' packageJsonUrl='node_modules/test/package.json' n=10000   ±1.62% ±2.12%
esm/esm-legacyMainResolve.js resolvedFile='node_modules/test/index.js' packageConfigMain='' packageJsonUrl='node_modules/test/package.json' n=10000             ±2.09% ±2.74%
esm/esm-legacyMainResolve.js resolvedFile='node_modules/test/index.json' packageConfigMain='./index.js' packageJsonUrl='node_modules/test/package.json' n=10000 ±1.74% ±2.27%
esm/esm-legacyMainResolve.js resolvedFile='node_modules/test/index.json' packageConfigMain='' packageJsonUrl='node_modules/test/package.json' n=10000           ±1.53% ±1.99%
esm/esm-legacyMainResolve.js resolvedFile='node_modules/test/index.node' packageConfigMain='./index.js' packageJsonUrl='node_modules/test/package.json' n=10000 ±1.91% ±2.48%
esm/esm-legacyMainResolve.js resolvedFile='node_modules/test/index.node' packageConfigMain='' packageJsonUrl='node_modules/test/package.json' n=10000           ±1.77% ±2.31%

Be aware that when doing many comparisons the risk of a false-positive
result increases. In this case, there are 8 comparisons, you can thus
expect the following amount of false-positive results:
  0.40 false positives, when considering a   5% risk acceptance (*, **, ***),
  0.08 false positives, when considering a   1% risk acceptance (**, ***),
  0.01 false positives, when considering a 0.1% risk acceptance (***)

To be able to run the benchmark, first build the old node using this branch.

About the benchmark, I needed to create another benchmark just for this function to be able to see the improvements since the results of esm-defaultResolver.js was not reflecting the real impact of this change.

Potential optimizations

legacyMainResolve also calls fileURLToPath and didn't have any version on the C++ side, so I needed to rewrite this function.

I haven't benchmarked the JS version yet, but I think we can add some benchmarks and see if we can replace the JS version with the C++ version, I've tried to make the code as easy as possible to support exposing on the JS side in the future.

Tasks

Rewrite legacyMainResolve
Rewrite fileURLToPath
Add benchmark for legacyMainResolve
Add tests for legacyMainResolve

Acknowledgments

Huge thanks to @anonrig for the support and early review of this code and @RafaelGSS for the hints about the benchmark and permission model.

Review requested:

@nodejs/loaders
@nodejs/modules

IMO the new implementation is prone to memory leaks and it's quite complex to read

Wouldn't it block the event loop?

This function seems to be the same as

node/src/node_file.cc

Line 1124 in 4bb06db

static void InternalModuleStat(const FunctionCallbackInfo<Value>& args) {

maybe we could DRY the implementation of both here? (this not really blocking just a observation)

Initially, I was thinking of doing that but I cannot join both functions since I don't know how I can represent the state of the THROW_IF_INSUFFICIENT_PERMISSIONS, when the user doesn't have permissions, we should stop the execution of the function, so I need to return not only an int but also another state to tell the caller that the user doesn't have permission.

Because of this, I prefer to return an enum for FilePathIsFile and not over complicate both implementations.

@RafaelGSS might help

legacyMainResolve also calls fileURLToPath and didn't have any version on the C++ side, so I needed to rewrite this function.

Maybe we should first test/benchmark and land the fileURLToPath rewrite, which would simplify this PR. wdyt?

@aduh95 Here's the benchmark for the rewrite of fileURLToPath:

IMPORTANT: Those values are not related to this PR, those numbers are only specific to the branch linked above the benchmark.

                                                                                         confidence improvement accuracy (*)    (**)   (***)
url/file-url-to-path.js n=100000 url='(url) file:///home/user/test/index.js'                    ***    -95.88 %       ±3.25%  ±4.44%  ±6.03%
url/file-url-to-path.js n=100000 url='(url) file:///home/user/test%20index.js'                  ***    -95.19 %       ±2.98%  ±4.07%  ±5.52%
url/file-url-to-path.js n=100000 url='(url) file:///home/user/test%2Findex.js'                  ***      8.66 %       ±2.71%  ±3.67%  ±4.90%
url/file-url-to-path.js n=100000 url='(url) file://google.com/home/user/test%2Findex.js'                 0.68 %       ±2.75%  ±3.72%  ±4.99%
url/file-url-to-path.js n=100000 url='(url) http://google.com/home/test.js'                     ***    -11.02 %       ±2.27%  ±3.05%  ±4.03%
url/file-url-to-path.js n=100000 url='file:///home/user/test/index.js'                          ***     97.59 %       ±7.74% ±10.45% ±13.92%
url/file-url-to-path.js n=100000 url='file:///home/user/test%20index.js'                        ***     86.08 %       ±7.51% ±10.15% ±13.52%
url/file-url-to-path.js n=100000 url='file:///home/user/test%2Findex.js'                        ***    195.47 %       ±3.95%  ±5.35%  ±7.14%
url/file-url-to-path.js n=100000 url='file://google.com/home/user/test%2Findex.js'              ***    166.80 %       ±3.19%  ±4.29%  ±5.66%
url/file-url-to-path.js n=100000 url='http://google.com/home/test.js'                           ***    145.18 %       ±4.26%  ±5.76%  ±7.68%
url/file-url-to-path.js n=100000 url='not-even-a-url'                                           ***    168.09 %       ±7.25%  ±9.87% ±13.32%

Be aware that when doing many comparisons the risk of a false-positive
result increases. In this case, there are 11 comparisons, you can thus
expect the following amount of false-positive results:
  0.55 false positives, when considering a   5% risk acceptance (*, **, ***),
  0.11 false positives, when considering a   1% risk acceptance (**, ***),
  0.01 false positives, when considering a 0.1% risk acceptance (***)

Branch: main...h4ad-forks:node:perf/file-url-to-path

In resume, if we want to expose the C++ function, we should enforce the caller to always pass a string instead of URL.

@H4ad I meant to have it as a separate PR.

@aduh95 Yeah, my idea was to show you if you really want to do that with the performance benefits from it.

To be honest, in this form, without refactoring the whole ESM to avoid new URL and manipulate the data directly as a string, we will not see a performance improvement, it will be the complete opposite.

I think is better to go in the opposite direction, merge this one and then evaluate the benefits of exposing fileURLToPath, because as I said, will probably lead to a refactoring not only in the function itself but also in the places where they call to take the fastest path, which is manipulating directly the string.

url/file-url-to-path.js n=100000 url=’(url) file:///home/user/test/index.js’ *** -95.88 % ±3.25% ±4.44% ±6.03%

This seems to show that in the most common case of a file:// URL, this is 96% slower?

@GeoffreyBooth Exactly, the way the fileURLToPath is used today, simply don't worth exposing the C++ version.

@GeoffreyBooth Exactly, the way the fileURLToPath is used today, simply don’t worth exposing the C++ version.

Okay, so then should we close this PR? Is there something else of value being proposed here?

This PR is not about fileURLToPath, is about LegacyMainResolve.

The improvements for LegacyMainResolve is about 60~70%.

The rewrite of fileURLToPath was only because it was needed by LegacyMainResolve. Aduh suggested that maybe we could create a PR for fileURLToPath but as we've seen, it's not worth it, that's it.

Also, the metrics of #48325 (comment) is not related to this PR itself, are related to the branch I link in the comment, so those numbers don't reflect this PR since we don't have any overhead of calling C++ function from C++ side.

The CI for Test Asan is failing due some memory issue:

==88318==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7ffd9ad085f8 at pc 0x00000431f995 bp 0x7ffd9ad07570 sp 0x7ffd9ad07568
READ of size 16 at 0x7ffd9ad085f8 thread T0
    #0 0x431f994 in ada::url_aggregator ada::parser::parse_url<ada::url_aggregator>(std::basic_string_view<char, std::char_traits<char> >, ada::url_aggregator const*) (/home/runner/work/node/node/out/Release/node+0x431f994)
    #1 0x4312e13 in tl::expected<ada::url_aggregator, ada::errors> ada::parse<ada::url_aggregator>(std::basic_string_view<char, std::char_traits<char> >, ada::url_aggregator const*) (/home/runner/work/node/node/out/Release/node+0x4312e13)
    #2 0xfc3b97 in node::fs::LegacyMainResolve(v8::FunctionCallbackInfo<v8::Value> const&) (/home/runner/work/node/node/out/Release/node+0xfc3b97)
    #3 0x1779bab in v8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper<false>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::FunctionTemplateInfo>, v8::internal::Handle<v8::internal::Object>, unsigned long*, int) (/home/runner/work/node/node/out/Release/node+0x1779bab)
    #4 0x17779b4 in v8::internal::Builtin_HandleApiCall(int, unsigned long*, v8::internal::Isolate*) (/home/runner/work/node/node/out/Release/node+0x17779b4)
    #5 0x3402e35 in Builtins_CEntry_Return1_ArgvOnStack_BuiltinExit (/home/runner/work/node/node/out/Release/node+0x3402e35)

Address 0x7ffd9ad085f8 is located in stack of thread T0 at offset 1304 in frame
    #0 0xfc364f in node::fs::LegacyMainResolve(v8::FunctionCallbackInfo<v8::Value> const&) (/home/runner/work/node/node/out/Release/node+0xfc364f)

Ref: https://github.com/nodejs/node/actions/runs/5189308542/jobs/9354128411?pr=48325

Does anyone know what could be the cause?

I tried to reproduce it locally but I couldn't, so I have no idea how to fix it.

PR-URL: nodejs#48664 Refs: nodejs#48325 Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com> Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>

Instead of many C++ calls, now we make only one C++ call to return a enum number that represents the selected state. PR-URL: nodejs#48325 Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com> Reviewed-By: Geoffrey Booth <webadmin@geoffreybooth.com> Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>

PR-URL: nodejs#48664 Refs: nodejs#48325 Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com> Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>

This commit does not land cleanly on v18.x-staging and will need manual backport in case we want it in v18.

PR-URL: #48664 Refs: #48325 Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com> Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>

@ruyadorno Hey, can I help with something?

@H4ad does https://github.com/nodejs/node/blob/main/doc/contributing/backporting-to-release-lines.md#how-to-submit-a-backport-pull-request help?

@RaisinTen Thanks, I'll try to backport by the end of this day.

PR-URL: #48664 Refs: #48325 Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com> Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>

PR-URL: #49688 Refs: #48325 Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>

nodejs-github-bot added c++ Issues and PRs that require attention from people who are familiar with C++. esm Issues and PRs related to the ECMAScript Modules implementation. fs Issues and PRs related to the fs subsystem / file system. needs-ci PRs that need a full CI run. labels Jun 3, 2023

H4ad force-pushed the perf/legacy-main-resolve branch from 95e1aa7 to 55dd4d9 Compare June 3, 2023 19:43

H4ad mentioned this pull request Jun 3, 2023

Improve legacy CJS resolve nodejs/performance#73

Closed

RafaelGSS reviewed Jun 3, 2023

View reviewed changes

This comment was marked as duplicate.

Sign in to view

anonrig reviewed Jun 3, 2023

View reviewed changes

Comment thread lib/internal/modules/esm/resolve.js Outdated

Comment thread lib/internal/modules/esm/resolve.js Outdated

Comment thread src/node_file.cc Outdated

Comment thread src/node_file.cc Outdated

H4ad force-pushed the perf/legacy-main-resolve branch 2 times, most recently from 232d48c to 072c7d2 Compare June 4, 2023 03:21

anonrig reviewed Jun 4, 2023

View reviewed changes

debadree25 reviewed Jun 4, 2023

View reviewed changes

H4ad force-pushed the perf/legacy-main-resolve branch from 072c7d2 to dbacd5f Compare June 4, 2023 15:33

RafaelGSS reviewed Jun 4, 2023

View reviewed changes

H4ad force-pushed the perf/legacy-main-resolve branch from dbacd5f to 9301722 Compare June 5, 2023 02:29

H4ad marked this pull request as ready for review June 5, 2023 02:30

anonrig mentioned this pull request Jun 5, 2023

Node.js Technical Steering Committee (TSC) Meeting 2023-06-07 nodejs/TSC#1396

Closed

H4ad force-pushed the perf/legacy-main-resolve branch from 9301722 to 42f276c Compare June 6, 2023 13:43

RaisinTen reviewed Jun 8, 2023

View reviewed changes

Comment thread src/node_file.cc Outdated

ruyadorno added the backport-requested-v18.x label Sep 11, 2023

H4ad mentioned this pull request Sep 14, 2023

[v18.x backport] src,lib: reducing C++ calls of esm legacy main resolve #49644

Closed

RaisinTen added backport-open-v18.x and removed backport-requested-v18.x labels Sep 14, 2023

pluris mentioned this pull request Sep 16, 2023

src: move const variable in node_file.h to node_file.cc #49673

Closed

pluris mentioned this pull request Sep 17, 2023

src: move const variable in node_file.h to node_file.cc #49688

Merged

nodejs-github-bot pushed a commit that referenced this pull request Sep 29, 2023

src: move const variable in node_file.h to node_file.cc

43500fa

PR-URL: #49688 Refs: #48325 Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>

This was referenced Feb 14, 2024

[Bug]: Electron 29. "Cannot Find Packages" when targeting ESM electron/electron#41241

Closed

fix: ESM legacyMainResolve with asar electron/electron#41348

Closed

VerteDinde mentioned this pull request Feb 18, 2024

fix: revert to legacyMainResolve in JavaScript for asar compatibility electron/electron#41367

Merged

5 tasks

aduh95 mentioned this pull request Nov 3, 2024

[v18.x] esm: fix broken assertion in legacyMainResolve #55708

Closed

src,lib: reducing C++ calls of esm legacy main resolve by H4ad · Pull Request #48325 · nodejs/node · GitHub

Uh oh!

Uh oh!

src,lib: reducing C++ calls of esm legacy main resolve - #48325

src,lib: reducing C++ calls of esm legacy main resolve#48325nodejs-github-bot merged 2 commits intonodejs:mainnodejs/node:mainfrom h4ad-forks:perf/legacy-main-resolveh4ad-forks/node:perf/legacy-main-resolveCopy head branch name to clipboard

Conversation

H4ad commented Jun 3, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Legacy Main Resolve

Potential optimizations

Tasks

Acknowledgments

Uh oh!

nodejs-github-bot commented Jun 3, 2023

Uh oh!

RafaelGSS left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

RafaelGSS Jun 3, 2023

Choose a reason for hiding this comment

Uh oh!

This comment was marked as duplicate.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

debadree25 Jun 4, 2023

Choose a reason for hiding this comment

Uh oh!

H4ad Jun 4, 2023

Choose a reason for hiding this comment

Uh oh!

anonrig Jun 10, 2023

Choose a reason for hiding this comment

Uh oh!

aduh95 commented Jun 4, 2023

Uh oh!

H4ad commented Jun 4, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

aduh95 commented Jun 4, 2023

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

H4ad commented Jun 4, 2023

Uh oh!

GeoffreyBooth commented Jun 5, 2023

Uh oh!

H4ad commented Jun 6, 2023

Uh oh!

GeoffreyBooth commented Jun 6, 2023

Uh oh!

H4ad commented Jun 6, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

H4ad commented Jun 7, 2023

Uh oh!

Uh oh!

ruyadorno commented Sep 11, 2023

Uh oh!

H4ad commented Sep 11, 2023

Uh oh!

RaisinTen commented Sep 11, 2023

Uh oh!

src,lib: reducing C++ calls of esm legacy main resolve#48325
nodejs-github-bot merged 2 commits into
nodejs:mainfrom
h4ad-forks:perf/legacy-main-resolve

H4ad commented Jun 3, 2023 •
edited
Loading

H4ad commented Jun 4, 2023 •
edited
Loading

H4ad commented Jun 6, 2023 •
edited
Loading