All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Kastrup <dak@gnu.org>
To: Christian Jaeger <chrjae@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: git gc --aggressive led to about 40 times slower "git log --raw"
Date: Tue, 18 Feb 2014 09:55:23 +0100	[thread overview]
Message-ID: <87r470ssuc.fsf@fencepost.gnu.org> (raw)
In-Reply-To: <CAEjYwfU==yYtQBDzZzEPdvbqz1N=gZtbMr5ccRaC_U7NfViQLA@mail.gmail.com> (Christian Jaeger's message of "Tue, 18 Feb 2014 07:25:10 +0000")

Christian Jaeger <chrjae@gmail.com> writes:

> I've got a repository where "git log --raw > _somefile" took a few
> seconds in the past, but after an attempt at merging some commits that
> were collected in a clone of the same repo that was created about a
> year ago, I noticed that this command was now taking 3 minutes 7
> seconds. "git gc", "git fsck", "git clone file:///the/repo/.git" also
> now each took between ~4-10 minutes, also "git log --raw somefile" got
> equally unusably slow. With the help of the people on the IRC, I
> tracked it down to my recent use of "git gc --aggressive" in this
> repo. Running "git repack -a -d -f" solved it, now it's again taking
> 4-5 seconds. After running "git gc --aggressive" again for
> confirmation, "git log --raw > _somefile" was again slowed down,
> although now 'only' to 1 minute 34 seconds;

[...]

> I've now learned to avoid "git gc --aggressive". Perhaps there are
> some other conclusions to be drawn, I don't know.

I've seen the same with my ongoing work on git-blame with the current
Emacs Git mirror.  Aggressive packing reduces the repository size to
about a quarter, but it blows up the system time (mainly I/O)
significantly, quite reducing the total benefits of my algorithmic
improvements there.

There is also some quite visible additional time spent in zlib, so a
wild guess would be that zlib is not really suited to the massive amount
of directory entries of a Git object store.  Since the system time still
dominates, this guess would only make sense if Git over zlib kept
rereading the directory section of whatever compressed file we are
talking about.  But that's really a rather handwavy wild guess without
anything better than a hunch to back it up.  I don't even know what kind
of compression and/or packs are used: I've only ever messed myself with
the delta coding of the normal "unpacked" operation (there are a few
older commits from me on that).

-- 
David Kastrup

  reply	other threads:[~2014-02-18  9:36 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-18  7:25 git gc --aggressive led to about 40 times slower "git log --raw" Christian Jaeger
2014-02-18  8:55 ` David Kastrup [this message]
2014-02-18  9:45   ` Duy Nguyen
2014-02-18 10:25     ` David Kastrup
2014-02-18 15:59       ` Jonathan Nieder
2014-02-18 20:59         ` Junio C Hamano
2014-02-18 22:46           ` Duy Nguyen
2014-02-19  0:10             ` Junio C Hamano
2014-02-19  0:33               ` Duy Nguyen
2014-02-19  8:38                 ` Philippe Vaucher
2014-02-19  9:01                   ` David Kastrup
2014-02-19 10:24                     ` Duy Nguyen
2014-02-19 10:14                   ` Duy Nguyen
2014-02-20  4:09                     ` Christian Jaeger
2014-02-20 16:48                     ` David Kastrup
2014-02-20 17:06                       ` David Kastrup
2014-02-20 18:07                         ` David Kastrup
2014-02-19 18:59                   ` Junio C Hamano
2014-02-20 23:35                     ` Duy Nguyen
2014-02-21  0:32                       ` Christian Jaeger
2014-02-21 17:36                         ` Junio C Hamano
2014-02-21  5:09                       ` Duy Nguyen
2014-02-21 17:47                       ` Junio C Hamano
2014-02-24  9:27                         ` Philippe Vaucher
2014-02-22  0:36           ` Duy Nguyen
2014-02-22  6:20             ` David Kastrup
2014-02-22  8:53               ` David Kastrup
2014-02-22  9:14                 ` Duy Nguyen
2014-02-22 13:00                   ` Duy Nguyen
2014-02-22  9:57               ` Andreas Schwab
2014-02-18 16:43     ` Christian Jaeger

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=87r470ssuc.fsf@fencepost.gnu.org \
    --to=dak@gnu.org \
    --cc=chrjae@gmail.com \
    --cc=git@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.