Subject: Re: [PATCH v3 03/10] upload-pack: prefer flushing data over sending keepalive

From: Patrick Steinhardt <[email-masked]>
Date: Tue, 10 Mar 2026 18:43:07 +0100

On Tue, Mar 10, 2026 at 10:09:51AM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <[email-masked]> 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