Conversation
`DefaultScheduler.runImmediate` wrapped every task in a `DispatchWorkItem`, which allocates the work item and copies the task's block a second time. Every `NetworkContext.async` goes through it, which includes the hop that delivers each inbound datagram and the cleanup a stream schedules when it is torn down. The work item was only there because its initializer accepts a non-`Sendable` closure; the task is now handed to the queue directly, just as unchecked. Each task costs two allocations instead of four. Measured on my Mac against `main` with the package's QUIC benchmark tools. Allocation counts come from full malloc stack logging, which records every allocation: QUICTransfer -size 1200, per message 24.37 -> 22.14 QUICTransfer, per 500 KB transfer 6,187.6 -> 6,131.8 QUICHandshake, per connection 1,947.4 -> 1,941.5 QUICStreamLoad, per stream 111.8 -> 106.9 Wall-clock time comes from running `main`, this change and the other changes measured alongside it in a rotating order for 9 rounds, and comparing each run with `main`'s in the same round. Changes moved paths they do not touch by up to about 1.3%, so differences that size count as noise. The stream load took 1.4% less time, faster in 7 of 9 rounds; the transfers and the handshakes did not change beyond noise.
agnosticdev
reviewed
Oct 2, 2026
| // Tasks are not `Sendable`; the queue is what serializes them, so the task is handed over | ||
| // unchecked. Wrapping it in a `DispatchWorkItem` would skip the check too, but costs a work | ||
| // item and a second block copy on every task. | ||
| nonisolated(unsafe) let task = task |
Collaborator
There was a problem hiding this comment.
Any other way we can do this here without nonisolated?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
DefaultScheduler.runImmediatewrapped every task in aDispatchWorkItem,which allocates the work item and copies the task's block a second time. Every
NetworkContext.asyncgoes through it, which includes the hop that deliverseach inbound datagram and the cleanup a stream schedules when it is torn down.
The work item was only there because its initializer accepts a non-
Sendableclosure; the task is now handed to the queue directly, just as unchecked. Each
task costs two allocations instead of four.
Measured on my Mac against
mainwith the package's QUIC benchmark tools.Allocation counts come from full malloc stack logging, which records every
allocation:
Wall-clock time comes from running
main, this change and the other changesmeasured alongside it in a rotating order for 9 rounds, and comparing each run
with
main's in the same round. Changes moved paths they do not touch by up toabout 1.3%, so differences that size count as noise. The stream load took 1.4%
less time, faster in 7 of 9 rounds; the transfers and the handshakes did not
change beyond noise.