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@xxxxxxxxxx
OOO http://www.madism.org
Attachment:
pgpTuAkJ01ks0.pgp
Description: PGP signature
