Re: [PATCH v2] fetch-pack: grow stateless RPC windows exponentially
- From
- Jonathan Tan <jonathantanmy@google.com>
- Date
- Jul 19, 2016, 19:03 UTC
- Message-ID
- <CAGf8dgL3t7uX7yAux0xc2QMJJdmnM0262Quj4o6gDehwA+4JqQ@mail.gmail.com>
- In-Reply-To
- <CAGZ79kY+2PYx9oz9tvi0zG-oE6qS-Za7D3ocY1XtqcSsDchz0Q@mail.gmail.com>
On Tue, Jul 19, 2016 at 9:46 AM, Stefan Beller <sbeller@google.com> wrote:
Show 5 quoted lines
> Care to elaborate on why you choose 11/10 as growth factor? > > (As someone who has a tick in micro optimizing: > 9/8 is roughly the same exponent, but the division > by 8 is easier as it is just a shift by 3. Similar 17/16)
I don't have a specific reason for 11/10 as opposed to, say, 9/8 - I think that the time taken to execute this line is negligible compared to what's done in the calling code, but I'll change it to 9/8 if there is another reason for me to send another patch.
Show 8 quoted lines
> I guess one design criterion was 10 being a round number? > Does it make sense to experiment with the factor at all? > Digging into that, LARGE_FLUSH originates from 6afca450c3f, > (2011-03-20, fetch-pack: progressively use larger handshake windows), > and before we only had a linear growth. > > So I guess what I do not understand is why we need to slow down the > exponential growth at all?
The current code has an exponential (a' = a * 2) then a linear (a' = a + 1024) growth. I'm not slowing down the exponential growth - that part is retained. I'm replacing the linear growth with another conservative exponential growth (a' = a * 11 / 10).