Re: [PATCH] Add pack.depth option to git-pack-objects and change default depth to 50

From: Theodore Tso <tytso@mit.edu>
Date: May 8, 2007, 18:09 UTC
Message-ID: <20070508180947.GB15796@thunk.org>
In-Reply-To: <Pine.LNX.4.64.0705081848330.4167@racer.site>

On Tue, May 08, 2007 at 06:49:47PM +0200, Johannes Schindelin wrote:

> I'd be happier if that test was done on _at least_ the kernel repo, if not 
> something larger, _plus_ having the numbers on page faults. Swapping can 
> kill performance substantially...

Given how the delta cache works, I really don't think it's going to matter. In any case, my laptop has 2gigs of memory, and the kernel pack file is only 134megs, so you're not going to see any major page faults....

In any case, here is a quick run:

                git-gc                     git-log -S'object'     
             real/user/sys/min.faults   real/user/sys/min.faults  pack size
w=10,d=10    4:31/257.7/6.2/391711      5:53/326.9/1.7/255156     155940k
w=10,d=30    4:16/242.7/6.5/378193      5:39/331.6/2.3/437283     143144k
w=10,d=50    4:29/250.1/6.7/554493      5:43/334.5/1.9/362574     140080k

You'll note that it's the same thing; git-gc, git-log doesn't change much, while the pack size decreases as --depth increases. We're only seeing at 10% decrease in the pack size, compared to the 20% decrease with the git repository, but that's probably because of the HTML and man branches, which no doubt delta compress really, really well.

I can run a full set of benchmarks, varying both --window and --depth, and also including a non-pickaxe git-log test as requested, but not until tonight. I really don't think we'll see any surprises compared to the earlier runs, though.

After all, if we just stop and think about how the delta caching works, and how the repacking algorithm works, it's pretty clear that there shouldn't be any scaling issues with increasing --depth, and that increasing --window is just going to be painful, and these should hold true regardless of the size of the repo.

					- Ted