On Mon, Mar 14, 2011 at 04:48:38PM -0700, Shawn O. Pearce wrote: > Upon receiving "ACK %s ready" there is no point in looking at > the remaining commits inside of rev_list. Sending additional > "have %s" lines to the remote will not construct a smaller pack. > It is unlikely a commit older than the current cut point will have > a better delta base than the cut point itself has. > [...] > Assuming the client is only following the remote (and does not make > its own local commits), the client needs 11 rounds to spin through > the entire list of tags (32 commits per round, ceil(339/32) == 11). > Unfortunately the server knows on the first "have %s" line that > it can produce a good pack, and does not need to see the remaining > 320 tags in the other 10 rounds. Does this optimization help in that case? From looking at the code, it seems that we offer "ACK %s ready" only in the case that the client has something we do not. I.e., they _are_ building local commits on top. > Over smart HTTP, the client must do an additional 10 HTTP POST > requests, each of which incurs round-trip latency, and must upload > the entire state vector of all known common objects. On the final > POST request, this is 16 KiB worth of data. This optimization aside, I wonder if it is worth bumping up the number of haves we send in a chunk from 32 to something higher. -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