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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
