Re: Auto-gc in the background can take a long time to be put in the background
- Date: Mon, 25 Mar 2019 19:30:07 -0400
- From: Jeff King <peff@xxxxxxxx>
- Subject: Re: Auto-gc in the background can take a long time to be put in the background
On Tue, Mar 26, 2019 at 08:22:23AM +0900, Mike Hommey wrote:
> Recently, I've noticed that whenever the auto-gc message shows up about
> being spawned in the background, it still takes a while for git to
> return to the shell.
> I've finally looked at what it was stuck on, and it's
> `git reflog expire --all` taking more than 30s. I guess the question is
> whether there's a reason this shouldn't run in the background? Another
> is whether there's something that makes this slower than it should be.
The reason is that it takes locks which can interfere with other
operations; see 62aad1849f (gc --auto: do not lock refs in the
Unfortunately making it faster is hard. To handle expiring unreachable
items, it has to know what's reachable. Which implies walking the commit
graph. I don't recall offhand whether setting unreachable-expiration to
"never" would skip that part. But if not, that should be low-hanging
(I also wonder whether there is really much valuable in keeping
unreachable things for a shorter period of time, and the default should
simply be to just prune everything after 90 days, unreachable or not).