Skip to content

Conversation

@anonrig
Copy link
Member

 confidence improvement accuracy (*) (**) (***) fs/bench-mkdtempSync.js n=1000 type='invalid' *** 78.55 % ±18.94% ±25.20% ±32.82% fs/bench-mkdtempSync.js n=1000 type='valid' -0.72 % ±7.92% ±10.54% ±13.72% Be aware that when doing many comparisons the risk of a false-positive result increases. In this case, there are 2 comparisons, you can thus expect the following amount of false-positive results: 0.10 false positives, when considering a 5% risk acceptance (*, **, ***), 0.02 false positives, when considering a 1% risk acceptance (**, ***), 0.00 false positives, when considering a 0.1% risk acceptance (***) 

Ref: nodejs/performance#106

@nodejs-github-botnodejs-github-bot added c++ Issues and PRs that require attention from people who are familiar with C++. fs Issues and PRs related to the fs subsystem / file system. needs-ci PRs that need a full CI run. labels Sep 21, 2023
@anonriganonrig added performance Issues and PRs related to the performance of Node.js. request-ci Add this label to start a Jenkins CI on a PR. labels Sep 21, 2023
@github-actionsgithub-actionsbot removed the request-ci Add this label to start a Jenkins CI on a PR. label Sep 21, 2023
@nodejs-github-bot
Copy link
Collaborator

@nodejs-github-bot
Copy link
Collaborator

@anonriganonrig added the request-ci Add this label to start a Jenkins CI on a PR. label Sep 24, 2023
@github-actionsgithub-actionsbot removed the request-ci Add this label to start a Jenkins CI on a PR. label Sep 24, 2023
@nodejs-github-bot
Copy link
Collaborator

@anonriganonrigforce-pushed the fs-improve-mkdtempsync branch from e2ea13a to 476e8d4CompareSeptember 24, 2023 21:10
@nodejs-github-bot
Copy link
Collaborator

@nodejs-github-bot
Copy link
Collaborator

@Trott
Copy link
Member

@nodejs/fs @nodejs/cpp-reviewers

@anonriganonrig requested a review from QardSeptember 26, 2023 15:11
@anonriganonrigforce-pushed the fs-improve-mkdtempsync branch from 476e8d4 to 58a4bcdCompareSeptember 26, 2023 15:17
@anonriganonrig added the request-ci Add this label to start a Jenkins CI on a PR. label Sep 26, 2023
@github-actionsgithub-actionsbot removed the request-ci Add this label to start a Jenkins CI on a PR. label Sep 26, 2023
@nodejs-github-bot
Copy link
Collaborator

@JakobJingleheimer
Copy link
Member

For us luddites, I would love a TLDR for why this improved perf so drastically 😅

@anonrig
Copy link
MemberAuthor

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.

@nodejs-github-bot
Copy link
Collaborator

@nodejs-github-bot
Copy link
Collaborator

@nodejs-github-bot
Copy link
Collaborator

Copy link
Member

@benjamingrbenjamingr left a 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

SetMethod(isolate, target, "lutimes", LUTimes);

SetMethod(isolate, target, "mkdtemp", Mkdtemp);
SetMethodNoSideEffect(isolate, target, "mkdtempSync", MkdtempSync);
Copy link
Member

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?

Copy link
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes...

@anonriganonrig added the request-ci Add this label to start a Jenkins CI on a PR. label Sep 27, 2023
@github-actionsgithub-actionsbot removed the request-ci Add this label to start a Jenkins CI on a PR. label Sep 27, 2023
@nodejs-github-bot
Copy link
Collaborator


switch(type){
case'valid':
prefix=`${Date.now()}`;
Copy link
Member

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(leti=0;i<n;i++){
try{
constfolderPath=fs.mkdtempSync(prefix,{encoding: 'utf8'});
fs.rmdirSync(folderPath);
Copy link
Member

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.

}

functionmkdtemp(prefix,options){
options=getOptions(options);
Copy link
Member

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..

}

staticvoidMkdtempSync(const FunctionCallbackInfo<Value>& args){
Environment* env = Environment::GetCurrent(args);
Copy link
Member

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.

Copy link
MemberAuthor

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.

Copy link
Member

@joyeecheungjoyeecheungSep 27, 2023

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.

@anonrig
Copy link
MemberAuthor

Closing in favor of #49962

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

c++Issues and PRs that require attention from people who are familiar with C++.fsIssues and PRs related to the fs subsystem / file system.needs-ciPRs that need a full CI run.performanceIssues and PRs related to the performance of Node.js.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants

@anonrig@nodejs-github-bot@Trott@JakobJingleheimer@benjamingr@joyeecheung@rluvaton