Re: [PATCH WIP] sha1-lookup: make selection of 'middle' less aggressive

From: Pierre Habouzit <madcoder@debian.org>
Date: Jan 1, 2008, 14:51 UTC
Message-ID: <20080101145130.GD3893@artemis.madism.org>
In-Reply-To: <20080101063616.GA21605@coredump.intra.peff.net>

On Tue, Jan 01, 2008 at 06:36:16AM +0000, Jeff King wrote:

> zlib makes a noticeable impact in real world cases. On a git.git repo,
> fully packed with stock config, warm cache:

On linux-2.6.git, with compressed packs:

    $ =time git whatchanged >|/dev/null
    19.67user 1.24system 0:21.01elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
    0inputs+0outputs (0major+38556minor)pagefaults 0swaps

Without compression:

    $ =time git whatchanged >|/dev/null
    14.41user 1.23system 0:15.67elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
    0inputs+0outputs (0major+44678minor)pagefaults 0swaps

> More pagefaults, but a 25% improvement in wall clock time.  The packfile
> is noticeably larger (55M versus 40M), so I'm sure the cold cache case
> sucks. It may also change with larger repos, where the packfile size
> difference kills your cache.

  The packfile is _incredibly_ larger (~200Mo -> ~420, though I suppose
the first one was packed with a larger window, coming from kernel.org).
I experience the same 25% wall clock reduction here as well. Though,
even if larger, linux-2.6.git still stays in RAM easily on my machine.

  On an unrelated note, I wonder if it wouldn't be possible for git at
fetch time to "share" a very efficient pack that was computed on some
host. I mean, if I'm not mistaken, at clone time you get the efficient
pack, but at fetch time only incremental parts. I wonder if there would
be ways to say "hey, we recomputed here a very very very good pack, take
it instead of yours.

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org