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

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