Skip to content

Commit c422ec8

Browse files
pks-tgitster
authored andcommitted
upload-pack: prefer flushing data over sending keepalive
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. Suggested-by: Jeff King <peff@peff.net> Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
1 parent 5d4b7dd commit c422ec8

1 file changed

Lines changed: 15 additions & 6 deletions

File tree

upload-pack.c

Lines changed: 15 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -466,18 +466,27 @@ static void create_pack_file(struct upload_pack_data *pack_data,
466466
}
467467

468468
/*
469-
* We hit the keepalive timeout without saying anything; send
470-
* an empty message on the data sideband just to let the other
471-
* side know we're still working on it, but don't have any data
472-
* yet.
469+
* We hit the keepalive timeout without saying anything. If we
470+
* have pending data we flush it out to the caller now.
471+
* Otherwise, we send an empty message on the data sideband
472+
* just to let the other side know we're still working on it,
473+
* but don't have any data yet.
473474
*
474475
* If we don't have a sideband channel, there's no room in the
475476
* protocol to say anything, so those clients are just out of
476477
* luck.
477478
*/
478479
if (!ret && pack_data->use_sideband) {
479-
static const char buf[] = "0005\1";
480-
write_or_die(1, buf, 5);
480+
if (output_state->packfile_started && output_state->used > 1) {
481+
send_client_data(1, output_state->buffer, output_state->used - 1,
482+
pack_data->use_sideband);
483+
output_state->buffer[0] = output_state->buffer[output_state->used - 1];
484+
output_state->used = 1;
485+
} else {
486+
static const char buf[] = "0005\1";
487+
write_or_die(1, buf, 5);
488+
}
489+
481490
last_sent_ms = now_ms;
482491
}
483492
}

0 commit comments

Comments
 (0)