Re: [PATCH 1/2] fetch-pack: Finish negotation if remote replies "ACK %s ready"

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