Re: git repack command on larger pack file

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
--
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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]