Re: [PATCH v3 03/10] upload-pack: prefer flushing data over sending keepalive
- From
Patrick Steinhardt <ps@pks.im>
- Date
- Mar 10, 2026, 17:43 UTC
- Message-ID
- <abBYK8uNkv84uydC@pks.im>
- In-Reply-To
- <xmqq5x73wqzk.fsf@gitster.g>
On Tue, Mar 10, 2026 at 10:09:51AM -0700, Junio C Hamano wrote:
Show 23 quoted lines
> Patrick Steinhardt <ps@pks.im> writes: > > > When using the sideband in git-upload-pack(1) we know to send out > > keepalive packets in case generating the pack takes too long. These > > keepalives take the form of a simple empty pktline. > > > > In the preceding commit we have adapted git-upload-pack(1) to buffer > > data more aggressively before sending it to the client. This creates an > > obvious optimization opportunity: when we hit the keepalive timeout > > while we still hold on to some buffered data, then it makes more sense > > to flush out the data instead of sending the empty keepalive packet. > > > > This is overall not going to be a significant win. Most keepalives will > > come before the pack data starts, and once pack-objects starts producing > > data, it tends to do so pretty consistently. And of course we can't send > > data before we see the PACK header, because the whole point is to buffer > > the early bit waiting for packfile URIs. But the optimization is easy > > enough to realize. > > > > Do so and flush out data instead of sending an empty pktline. While at > > it, drop the useless > > Useless what?
Ugh. I was initially turning the allocation of `output_state` into an on-stack variable only to later realize that we explicitly allocate it because it might otherwise blow the stack. Seems like I didn't manage to fully drop the sentence that mentioned this change.
I'll remove this half-sentence.
Patrick