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

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

From
Jeff King <peff@peff.net>
Date
Apr 6, 2010, 06:02 UTC
Message-ID
<20100406060217.GF3901@coredump.intra.peff.net>
In-Reply-To
<7v1vetpw63.fsf@alter.siamese.dyndns.org>
On Mon, Apr 05, 2010 at 11:54:28AM -0700, Junio C Hamano wrote:
Show 11 quoted lines
> Jeff King <peff@peff.net> writes:
> 
> > Hmm. It looks like mark_reachable() stops traversing when it hits a
> > commit older than expire_total. I imagine that's to avoid going all the
> > way to the roots. But if we hit any unreachable entry, in_merge_bases()
> > is going to have to go all the way to the roots, anyway.
> 
> Yeah, an alternative is to keep the list of commits where the initial
> mark_reachable() run stopped, and instead of doing in_merge_bases(),
> lazily restart the traversal all the way down to root, and then rely
> solely on the REACHABLE bit from then on.

Ah, yeah, that is much more clever. It has the same worst case performance as what I proposed, but is much more optimistic that we won't have to do it at all.

Show 12 quoted lines
> > I wonder if, in addition to your patch, we should remove the
> > double-check in_merge_bases and simply report those old ones as
> > reachable. We may be wrong, but we are erring on the side of keeping
> > entries, and they will eventually expire in the regular cycle (i.e., 90
> > days instead of 30).
> >
> > All of that being said, your patch does drop Frans' case down to about
> > 1s of CPU time, so perhaps it is not worth worrying about beyond that.
> 
> I think a reasonable solution would be along the lines you described, but
> the patch you are responding to does err on the wrong side when a clock
> skew is there.  Does it matter?  Probably not.

True. With the technique you mentioned above, you would reverse your test and do:

  if (flags & REACHABLE)
    return 0;
  if (expanded_reachable_to_root)
    return 1; /* we know it's not */
  expand_reachable_to_root();
  return !(flags & REACHABLE);

I don't think I care enough to do a patch, though. I don't have a problem with you applying what you posted earlier.

-Peff
Previous: Junio C HamanoNext: Junio C Hamano
Message 11 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.