From: Jeff King <peff@peff.net>
Date: Wed, 20 Jul 2016 13:40:27 GMT
Subject: Re: [PATCH v2] fetch-pack: grow stateless RPC windows exponentially
Message-ID: <20160720134027.GA19194@sigill.intra.peff.net>
In-Reply-To: <20160719195347.GF29326@google.com>

On Tue, Jul 19, 2016 at 12:53:47PM -0700, Jonathan Nieder wrote:

> Junio C Hamano wrote:
> 
> > Even if it is conservative, I wonder if it is truly a good idea to
> > make it exponentially grow forever from that point of view.  Would
> > it give essentially the same result to you if we discard the patch
> > in question and just raise LARGE_FLUSH to 10k instead?
> 
> I don't think it would be essentially the same result.  As discussed
> before, unlike the bidi (ssh:// and git:// protocols) case, linear
> growth is expensive in the stateless-rpc (https://) case --- each
> round of negotiation requires re-sending the existing 'have's and
> requires the peer repeatedly processing this increasingly large list
> of 'have's.
> 
> For comparison, in the bidi case, linear growth of next_flush means
> sending a bounded number of 'have's per round and is quite sensible.
> 
> In the stateless-rpc case, linear growth means getting a bounded
> number of 'have's worth of benefit (new 'have's) in each round, in
> exchange for a linearly increasing cost (existing 'have's).  That is a
> high cost for limited benefit.  Exponential growth is a better deal.

This kind of reasoning would be great in the commit message (and if
possible, numbers showing empirical improvement). On reading it, I
understood the "what", but not why or to what extent the slower growth
is a problem.

-Peff