Uh oh!
There was an error while loading. Please reload this page.
Reduce allocations in Quic/HTTP3 - #104394
Conversation
Tagging subscribers to this area: @dotnet/ncl |
MihaZupan
commented
Jul 3, 2024
/azp run runtime-libraries-coreclr outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
ManickaP
left a comment
There was a problem hiding this comment.
Before this PR, WritesClosed was handled right after completing writes, logically next to each other. Now, the logic is split in different places. I know it's more efficient, but IMHO it's much harder to follow now and not mess up in the future.
I'll not block this PR on this, I'm just sharing my perspective.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
MihaZupan
commented
Jul 6, 2024
/azp run runtime-libraries-coreclr outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
As of #104035 we're now waiting for
WritesClosedon every request, and paying for the allocations backing thatTask. This PR attempts to claw that perf back.This does a couple of things:
ResettableValueTaskSource's final task was already signaled by the time someone first asked for theTask, avoid allocating the intermediateTaskCompletionSourceand itsTask.WritesClosedlater on in Http3'sSendAsync(after receiving the response) to make it more likely thatWritesClosedwill have been completed by the time we check, thus avoiding the allocations.cancellationTokenwhile waiting forWritesClosed-- @ManickaP I'm guessing that's desirable here?FlushSendBufferAsync