Skip to content

Fixes performance regression on pnpm installs #6760

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 5 commits into from
Apr 11, 2025
Merged

Fixes performance regression on pnpm installs #6760

merged 5 commits into from
Apr 11, 2025

Conversation

goloveychuk
Copy link
Contributor

@goloveychuk goloveychuk commented Apr 10, 2025 •
edited by arcanis
Loading

What's the problem this PR addresses?

  • We forgot the close the file descriptor when releasing JS files. This causes EMFILE on some jobs.
  • The cache was mistakenly removed from the libzip backend, causing install times to jump, especially on pnpm installs.

Fixes #6758

Checklist

  • I have set the packages that need to be released for my changes to be effective.
  • I will check that all automated PR checks pass before the PR gets reviewed.

@goloveychuk goloveychuk mentioned this pull request Apr 10, 2025
Closed
1 task
arcanis
arcanis reviewed Apr 10, 2025
View reviewed changes
packages/yarnpkg-libzip/sources/libzipImpl.ts Outdated
@@ -196,7 +184,7 @@ export class LibZipImpl implements ZipImpl {
const memory = this.libzip.HEAPU8.subarray(buffer, buffer + size);
const data = Buffer.from(memory);

return {data, compressionMethod};
return {data, compressionMethod, shouldBeCached: true};
Copy link
Member

Choose a reason for hiding this comment

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

I'd prefer shouldBeCached to be a class property than something returned by getFileSource, especially since it never changes (and probably doesn't have a good reason to ever change?).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I was thinking that backend could decide whether to cache on per file basis.
E.g for big compressed files. Or frequently requested files. You decide.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Please reply if you want per file or per class. I'll change tomorrow.

Copy link
Member

Choose a reason for hiding this comment

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

Let's go with a class property. I think if we were to implement such a dynamic caching logic there's a good chance the checks you mention would live inside the ZipFS rather than the backend.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Pushed

@arcanis arcanis merged commit 8ee9a3d into yarnpkg:master Apr 11, 2025
26 checks passed
@arcanis arcanis changed the title chore: close fd in js impl Fixes performance regression on pnpm installs Apr 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@arcanis arcanis arcanis left review comments

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

[Bug?]: Very slow Link step on 4.9.0 when nodeLinker: pnpm
2 participants
@goloveychuk @arcanis