Re: git repack command on larger pack file

From: Jeff King <peff@peff.net>
Date: Oct 27, 2015, 23:47 UTC
Message-ID: <20151027234752.GC4172@sigill.intra.peff.net>
In-Reply-To: <xmqq611ujfn0.fsf@gitster.mtv.corp.google.com>

On Sun, Oct 25, 2015 at 11:41:23PM -0700, Junio C Hamano wrote:

> Also it has to write more data to disk (see below), it has to find a
> good place to split, it has to adjust bookkeeping data at the pack
> boundary, in general it has to do more, not less, to produce split
> packs.  It would be surprising if it took less time.

This may go without saying, but the main cost in the write is that we have to zlib deflate the output. I don't have any numbers at hand, but when I've benchmarked serving fetches, it is often a balance game between CPU time spent on a more aggressive delta search and CPU time that goes into deflating the results of the search. Spending more CPU on the former may yield more and smaller deltas which pay for themselves in time spent on the latter.

There's definitely a balance point, and it varies from repo to repo, and even within repos from fetch to fetch. I wish I had better heuristics to report, but it's an ongoing thing I'm exploring. :)

-Peff