-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
fs: improve error performance for fs.mkdtempSync
#49750
Conversation
e2ea13a
to
476e8d4
Compare
@nodejs/fs @nodejs/cpp-reviewers |
476e8d4
to
58a4bcd
Compare
For us luddites, I would love a TLDR for why this improved perf so drastically 😅 |
Because the cost of throwing an error on C++ vs. the cost of throwing an error on JS is extremely different. We do lots of stuff on JavaScript land whenever we create an error. For example, hiding stack traces etc. On the other hand, C++ has this support out of the box. |
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.
Left one comment other than that LGTM, after fixing feel free to consider my review as a LGTM
src/node_file.cc
Outdated
@@ -3409,6 +3441,7 @@ static void CreatePerIsolateProperties(IsolateData* isolate_data, | |||
SetMethod(isolate, target, "lutimes", LUTimes); | |||
|
|||
SetMethod(isolate, target, "mkdtemp", Mkdtemp); | |||
SetMethodNoSideEffect(isolate, target, "mkdtempSync", MkdtempSync); |
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 needs to be SetMethod right?
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.
Yes...
|
||
switch (type) { | ||
case 'valid': | ||
prefix = `${Date.now()}`; |
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 should probably be wrapped with tmpdir.resolve(..)
for (let i = 0; i < n; i++) { | ||
try { | ||
const folderPath = fs.mkdtempSync(prefix, { encoding: 'utf8' }); | ||
fs.rmdirSync(folderPath); |
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.
Do we need to remove it here? I think as long as n does not exceed the number of combinations formed by the 6 random characters it should be fine to just leave them in the loop and let test common just delete the tmpdir on exit.
@@ -53,6 +56,25 @@ function copyFile(src, dest, mode) { | |||
); | |||
} | |||
|
|||
function mkdtemp(prefix, options) { | |||
options = getOptions(options); |
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.
hmm, not sure since we we started to move the sync implementations to a different file, but I gotta say I am not a fan because 1) this incurs an unnecessary hit to startup (even with deserialization) and 2) moving code around makes git blame
less useful, especially when it's useful to have the sync and the async version side by side for cross-reference..
@@ -2957,6 +2957,38 @@ static void Mkdtemp(const FunctionCallbackInfo<Value>& args) { | |||
} | |||
} | |||
|
|||
static void MkdtempSync(const FunctionCallbackInfo<Value>& args) { | |||
Environment* env = Environment::GetCurrent(args); |
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.
hmm, actually, why do we need a different binding? We could just change the sync branch of the original implementation to directly throw instead of passing the error down to ctx. This would avoid the repetition of most of the code here. We can probably tell if it's a sync call or not by checking the length of the arguments now.
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.
I personally find it a lot harder to optimize since the requirements for promise implementation, sync and callback implementations are connected a lot.
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.
Why would it be a lot harder to optimize? We just need to introduce another SyncCall
helper that throws instead of setting the ctx and use that in the original implementation, and it's essentially the same as what's being done here? Then that helper can be used across the board for similar optmizations.
Closing in favor of #49962 |
Ref: nodejs/performance#106