-
Notifications
You must be signed in to change notification settings - Fork 29.1k
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,lib: reducing C++ calls of esm legacy main resolve #48325
src,lib: reducing C++ calls of esm legacy main resolve #48325
Conversation
Review requested:
|
95e1aa7
to
55dd4d9
Compare
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.
IMO the new implementation is prone to memory leaks and it's quite complex to read
src/node_file.cc
Outdated
THROW_IF_INSUFFICIENT_PERMISSIONS( | ||
env, permission::PermissionScope::kFileSystemRead, file_path); | ||
|
||
if (UNSAFE_FileExist(env, file_path)) return args.GetReturnValue().Set(0); |
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.
Wouldn't it block the event loop?
232d48c
to
072c7d2
Compare
src/node_file.cc
Outdated
#endif | ||
} | ||
|
||
FilePathIsFileReturnType FilePathIsFile(Environment* env, |
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.
This function seems to be the same as
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)
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.
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.
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.
@RafaelGSS might help
Maybe we should first test/benchmark and land the |
072c7d2
to
dbacd5f
Compare
@aduh95 Here's the benchmark for the rewrite of
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 I think is better to go in the opposite direction, merge this one and then evaluate the benefits of exposing |
dbacd5f
to
9301722
Compare
This seems to show that in the most common case of a |
@GeoffreyBooth Exactly, the way the |
Okay, so then should we close this PR? Is there something else of value being proposed here? |
This PR is not about The improvements for The rewrite of 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. |
9301722
to
42f276c
Compare
The CI for Test Asan is failing due some memory issue:
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. |
@ruyadorno Hey, can I help with something? |
@RaisinTen Thanks, I'll try to backport by the end of this day. |
Instead of many C++ calls, now we make only one C++ call to return a enum number that represents the selected state. Backport-PR-URL: nodejs#48325
Instead of many C++ calls, now we make only one C++ call to return a enum number that represents the selected state. Backport-PR-URL: nodejs#48325
Instead of many C++ calls, now we make only one C++ call to return a enum number that represents the selected state. Backport-PR-URL: nodejs#48325
Instead of many C++ calls, now we make only one C++ call to return a enum number that represents the selected state. Backport-PR-URL: nodejs#48325
PR-URL: nodejs#49688 Refs: nodejs#48325 Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Instead of many C++ calls, now we make only one C++ call to return a enum number that represents the selected state. Backport-PR-URL: nodejs#48325
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> Backport-PR-URL: nodejs#48664
PR-URL: nodejs#49688 Refs: nodejs#48325 Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
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:
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 callsfileURLToPath
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
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.