Re: Auto-gc in the background can take a long time to be put in the background

From: Jeff King <peff@peff.net>
Date: Mar 25, 2019, 23:30 UTC
Message-ID: <20190325233007.GA23728@sigill.intra.peff.net>
In-Reply-To: <20190325232223.r72qtffyzn5qzoxc@glandium.org>

On Tue, Mar 26, 2019 at 08:22:23AM +0900, Mike Hommey wrote:

Show 8 quoted lines

> 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 background, 2014-05-25).

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

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

-Peff