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