Re: Re*: Extremely slow progress during 'git reflog expire --all'

[Jeff King <peff@peff.net>]

On Wed, Apr 07, 2010 at 11:43:22AM -0700, Junio C Hamano wrote:

> Side note.
> 
> It may be an improvement to dig the history even more incrementally.

I doubt it matters much in practice. The important features of the
solution are:

  - for most refs, which are either all-reachable or which don't have
    clock skew, don't go to the roots at all. This is the fast case that
    we should do most of the time.

  - for others, don't go to the roots over and over for each entry. This
    is the slow case, but we just need to make sure it's a not the
    horrible slow case that Frans saw.

Your suggestion speeds up the slow case a little bit, but it is already
acceptably fast. Plus this is an optimistic optimization. There are
still cases where you might have to dig to the roots anyway (e.g.,
whenever you have anything unreachable).

> Inside unreachable(), we currently dig immediately down to root, but it
> may give us a better performance in a long history with reflog entries
> that wildly jump everywhere in that history if we dug down to the
> timestamp of the commit we are looking at.  A patch to do so on top of the
> previous one may look like this.

Why dig to the timestamp? You know you're looking for a particular
commit, so you can dig down to that commit. If it's reachable, stop
there and you have your answer. Any work you do beyond that might be
used for a further entry lookup, but it might not at all. If it's not
reachable, then you're going to end up digging down to the roots anyway.

With an unreachable ref and your scheme, you would just end up not
finding it, extending again, not finding it, extending again, etc. But
you can never be sure it's truly unreachable without going to the roots
or assuming no clock skew, so that is what we'll end up doing.

-Peff