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 26, 2019, 13:25 UTC
Message-ID: <20190326132512.GA22580@sigill.intra.peff.net>
In-Reply-To: <87k1gmb03v.fsf@evledraar.gmail.com>

On Tue, Mar 26, 2019 at 07:50:28AM +0100, Ævar Arnfjörð Bjarmason wrote:

Show 8 quoted lines

> > 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 have a recently patch that does this that I need to re-roll:
> https://public-inbox.org/git/20190315155959.12390-8-avarab@gmail.com/

I think your patch skips calling git-reflog when both are set to "never". What I mean is that if regular expiration is set to 90 days, and unreachable expiration is set to 90 days (or greater), the there is no need for us to bother walking any history. An entry is either expired based on time or it is not, regardless of reachability.

Show 6 quoted lines

> > (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).
> 
> Do you mean unify gc.reflogExpire & gc.pruneExpire (and other
> variables). Would that be cheaper somehow?

Yes, this. If we're just expiring based on the timestamp in the reflog, we should be able to accomplish this with just a single pass over the reflog data, and never opening any objects at all.

> Or just blindly remove loose objects that are older than some mtime,
> assuming that if anyone cared they'd be in a pack already?

No, definitely not. We're expiring reflogs here, not objects.

-Peff