git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Jeff King <peff@peff.net>
Date
Apr 8, 2010, 07:00 UTC
Message-ID
<20100408070050.GG30473@coredump.intra.peff.net>
In-Reply-To
<7vk4sjcddh.fsf@alter.siamese.dyndns.org>
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).

Show 5 quoted lines
> 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
Previous: Junio C HamanoNext: Jeff King
Message 14 of 15 in “Extremely slow progress during 'git reflog expire --all'”
  1. Frans PopApr 2, 2010
  2. Jeff KingApr 2, 2010
  3. Frans PopApr 2, 2010
  4. Jeff KingApr 2, 2010
  5. Frans PopApr 3, 2010
  6. Jeff KingApr 3, 2010
  7. Jeff KingApr 3, 2010
  8. Junio C HamanoApr 4, 2010
  9. Jeff KingApr 5, 2010
  10. Junio C HamanoApr 5, 2010
  11. Jeff KingApr 6, 2010
  12. Re*: Extremely slow progress during 'git reflog expire --all'Junio C Hamano, Apr 7, 2010
  13. Junio C HamanoApr 7, 2010
  14. Jeff KingApr 8, 2010
  15. Jeff KingApr 8, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.