git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH] gc --auto: warn garbage collection happens soon
Date: Wed, 28 Dec 2011 13:40:00 -0500	[thread overview]
Message-ID: <20111228184000.GA18780@sigill.intra.peff.net> (raw)
In-Reply-To: <7vpqf94r8c.fsf@alter.siamese.dyndns.org>

On Tue, Dec 27, 2011 at 01:52:35PM -0800, Junio C Hamano wrote:

> And if the answer to that tongue-in-cheek question is no, what is the
> reason why the users will not find the messages disturbing, while loathing
> the auto-gc?
> 
> I suspect that is because auto-gc takes long time, making the user wait,
> compared to the new message that may be noisy but quick.  Perhaps the real
> cure for the disease is not to add the message but to make an auto-gc less
> painful, no?
> 
> What are the things we could do to make auto-gc less painful?
>
> Are we doing something that is not necessary in auto-gc that takes time
> but that we can live without doing?

I don't personally find gc all that painful (though maybe that is
because I tend to gc myself and rarely hit the auto-gc), but I have
noticed that git-prune takes by far the most time to run. If you are
just doing an incremental pack, you might be packing only a few thousand
objects and not touching old history at all (and with many cores, the
delta compression flies by). But prune requires running "git rev-list
--objects --all", which takes something like 45 seconds for linux-2.6 on
my fast-ish laptop (and about 23 seconds for git.git).

We could perhaps cut out pruning in the auto-gc case unless there are a
lot of objects left over after the packing phase. It's not worth doing a
full prune to clean up a dozen objects[1]. It probably is if you have a
thousand objects left after packing.

-Peff

[1] Actually, it's not just having objects. You may have just exploded
    unreachable objects from a pack, but they are still younger than the
    2 week expiration period. Therefore trying to prune them is
    pointless, because even if they are unreachable, you won't delete
    them. So you really want to say "how many actual candidate objects
    do we have for pruning?"

  reply	other threads:[~2011-12-28 18:40 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-27 13:45 [PATCH] gc --auto: warn garbage collection happens soon Nguyễn Thái Ngọc Duy
2011-12-27 21:52 ` Junio C Hamano
2011-12-28 18:40   ` Jeff King [this message]
2011-12-28 20:02     ` Junio C Hamano
2011-12-28 21:30       ` Jeff King
2011-12-28 22:09         ` Nguyen Thai Ngoc Duy
2011-12-28 21:50   ` Nguyen Thai Ngoc Duy
2011-12-29 18:29   ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111228184000.GA18780@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=pclouds@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).