-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
libgit2, GitRepo: Write (thin) packfiles #11330
Conversation
@emilazy Could you test this on your mac?
|
Here you go:
Looks like a big improvement! Going to run without the dummy store now too. cc @cigrainger who seemed to have it much worse than me |
Without the dummy store:
Is the packfile stuff pure overhead over whatever previous Nix versions were doing? i.e., are the measurements in my previous comment how much slower current Nix is over 2.18? Or are they accomplishing part of the work that 2.18 was? These results still feel slow to me, though I never really measured before. (Still, clearly a huge improvement over the status quo!) |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2024-08-19-nix-team-meeting-minutes-170/50942/1 |
I think the benefit would only come once we would stop copying nixpkgs to the nix store which is also slow and use lazy-trees instead. However just now this is not the case. |
|
Or I guess you just mean, there’s still overhead over 2.18 that currently brings no benefit, even after this change? |
The reason the performance in current nix is different than in nix 2.18 is than in 2.24 is that nix now creates a git repository of all tarballs in ~/.cache/nix/tarball-cache and creates the nar hash from there only to copy the nixpkgs afterwards to the /nix/store again. I believe this was done to save disk space? A the moment it doesn't but we pay more compute and storage for maintaining the cache without getting the benefits for it by not having to copy the nixpkgs to the nix store. |
I see. That definitely seems like something that should be turned off until it can actually pay dividends. |
Agreed. The premise back than was that we would have the complete implementation sooner. But this did not work out. |
... yet. With a combination of this, #11367 and one or two edits, As we're finishing up the meson migration, I think we can focus on stabilizing that. It's a weaker version of lazy-trees #6530 that doesn't sacrifice correctness. It's "weaker" because Nixpkgs patch for loading module
|
I agree, and I am sorry that we overlooked this situation. I don't know what else to say except we're a volunteer team under a lot of pressure, but I'll stop complaining. I've talked to the team about this and while there's concern about "making a step back", we should consider this more so as a step sideways to avoid a regression. Personally I'd prefer to deliver #11367 over reinventing a solution to use the store as a cache again; it's not a simple revert unfortunately, but probably the old code is still useful. If anyone wants to try this, I'd still welcome such a PR. |
That sounds great. However do you think as a short term solution we should to re-introduce the the old code as the default code branch until both pull requests are fleshed out, so we don't have to rush an implementation? I would look into this, if we I get green light on this. |
Nice! That’s very exciting.
Don’t get me wrong; I appreciate the work. Copying is one of the most painful parts of flakes and you’re clearly taking it seriously. If this was behind an experimental flag or whatever I’d have no complaint, but in the context where Nixpkgs is trying to bump to a newer Nix version, it does seem pretty bad for some users to get significant flake copying performance regressions for what is apparently no benefit in the version Nixpkgs would be bumping to. I assumed that things had become slower for “complicated” reasons; if it really can just be switched off with no downside in the 2.24 branch that seems like a clear win to me. |
Another edge-case is NFS-baked home that can be found in universities quite often. |
a7192e3
to
30a2b4a
Compare
libgit2 didn't write thin ones, hence the patch. This should improve performance on systems with weak I/O in ~/.cache, especially in terms of operations per second, or where system calls are slower. (macOS, VMs?)
The latter is not used for memory synchronization things.
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2024-08-26-nix-team-meeting-minutes-172/51300/1 |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2024-08-02-nix-team-meeting-minutes-174/51512/1 |
Author: Robert Hensing <[email protected]> | ||
Date: Sun Aug 18 20:20:36 2024 +0200 | ||
|
||
Add unoptimized git_mempack_write_thin_pack |
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.
unoptimized
After reading libgit2 again, this optimization is performed by the later call to git_packbuilder_write_buf
instead. It is not a responsibility.
I've removed this from the PR I've submitted upstream
src/libfetchers/git-utils.cc
Outdated
panic("PackBuilderContext::handleException: user error, but exception not set"); | ||
|
||
std::rethrow_exception(exception); | ||
panic("PackBuilderContext::handleException: exception not thrown"); |
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.
panic("PackBuilderContext::handleException: exception not thrown"); |
src/libfetchers/git-utils.cc
Outdated
git_packbuilder_set_callbacks(packBuilder.get(), PACKBUILDER_PROGRESS_CHECK_INTERRUPT, &packBuilderContext); | ||
git_packbuilder_set_threads(packBuilder.get(), 0 /* autodetect */); | ||
|
||
// TODO: For an optimal pack it's mandatory to insert objects in recency order, commits followed by trees and blobs. |
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.
// TODO: For an optimal pack it's mandatory to insert objects in recency order, commits followed by trees and blobs. |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2024-09-09-nix-team-meeting-minutes-176-175/51852/1 |
I am daily driving this pull request on my machines for some time now btw. |
Motivation
This improves performance on systems with weak I/O in
~/.cache
, especially in terms of operations per second, or where system calls are slower. (macOS, VMs?)May address
Context
git_mempack_write_thin_pack
libgit2/libgit2#6875TODO
Priorities and Process
Add 👍 to pull requests you find important.
The Nix maintainer team uses a GitHub project board to schedule and track reviews.