Skip to content
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

[speculative] Store cache files in bundle #257

Open
pfitzseb opened this issue Jul 25, 2022 · 3 comments
Open

[speculative] Store cache files in bundle #257

pfitzseb opened this issue Jul 25, 2022 · 3 comments
Labels
enhancement New feature or request

Comments

@pfitzseb
Copy link
Member

Much like the registry is nowadays stored in a single tar file.

This will help with performance on file systems that are slow when accessing many small files and also with overeager antivir software.

@davidanthoff
Copy link
Member

Is that really a problem? I would have thought that the number of files we typically open is still small enough that this all works? Plus, not clear to me what the "bundle" unit would be? One gigantic file for all cached stuff? Then we need selective loads, which seems very involved...

@pfitzseb
Copy link
Member Author

Apparently it can be, yes. I don't have a machine I can repro this on, but we got reports of a ~3x slowdown.

One gigantic file for all cached stuff? Then we need selective loads, which seems very involved...

Yes, it's not entirely clear whether this is worth the effort. Appending to a binary (e.g. a tarball) isn't very tricky though -- it's just a file system, basically.

@pfitzseb pfitzseb changed the title Store cache files in bundle [speculative] Store cache files in bundle Jul 25, 2022
@davidanthoff
Copy link
Member

Hm, I still find this weird :) Essentially the number of files we need to load is equal to the number of precompile files that Julia needs to load, right? And that doesn't seem like a bottleneck?

The registry scenario seems like a completely different beast, I think? Wasn't the problem there updating it, because one had to read so many different files? But our update story is quite different, I think?

One thing we could do is use telemetry to get a sense how many deps a Manifest.toml typically has, that might be useful to think this through.

@davidanthoff davidanthoff added the enhancement New feature or request label Oct 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants