Repository navigation
perf(server): avoid stream callback allocation for calls without input streams - #678
Merged
Merged
Conversation
SunSi12138
marked this pull request as ready for review
September 12, 2026 23:59
This was referenced Sep 13, 2026
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
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.
Problem and change
Calls with no input streams entered a reservation method whose captured lambdas caused the compiler to allocate callback state before the existing zero-stream early return. Allocation tracing of the release's 64-message OneWay workload identified
SharpLinkServer.<>c__DisplayClass348_0fromReservePreInvocationRequestStreamsas an approximately 64-byte per-message allocation.Move captured callback construction into private streaming-only helpers, after the existing zero-stream guards. Apply the same guard boundary to pre-admission reservation. Input-stream reservation, compression decoding, retained-byte limits and terminal cleanup retain their existing implementation.
Validation
f61e1642316d9c14f48f477f97c82cc95bb3f909.0141a85andf61e164source builds; .NET 10.0.11 / macOS arm64 / M4 / server GC / 8 reported processors. Four dry cases passed; measurements used 8192 invocations, 6 warmup iterations, 12 measured iterations, unroll 1, with outliers retained.Errors are BenchmarkDotNet 99.9% confidence-interval half-widths. The OneWay result removes exactly 64 B/message (29% of the measured allocation) while time remains statistically unchanged. Upload time also remains unchanged within uncertainty. Timing measures client and server together over loopback; it does not replace final-main hardware ABA.
This addresses an independently measured allocation issue. It does not claim to resolve the separate baremetal TCP delivery stalls seen in release ABA diagnostics.