Skip to content

perf(server): avoid stream callback allocation for calls without input streams - #678

Merged
SunSi12138 merged 1 commit into
devfrom
fix/release-stream-reservation-allocation
Sep 13, 2026
Merged

SunSi12138 merged 1 commit into
devfrom
fix/release-stream-reservation-allocation

Conversation

@SunSi12138

@SunSi12138 SunSi12138 commented Sep 12, 2026 •

Copy link
Copy Markdown
Owner

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_0 from ReservePreInvocationRequestStreams as 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

  • Full non-incremental Release solution build: passed, 0 warnings / 0 errors.
  • Targeted pre-invocation retention, pre-admission stream-budget and OneWay deadline tests: 7 passed / 0 failed / 0 skipped.
  • Full unit tests: 1825 passed / 0 failed / 0 skipped. Integration tests: 451 passed / 0 failed / 0 skipped.
  • All eight NuGet packages packed successfully and verified against commit f61e1642316d9c14f48f477f97c82cc95bb3f909.
  • BenchmarkDotNet 0.15.8: identical loopback workloads against frozen 0141a85 and f61e164 source 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.
Workload Before After Allocation
64-message OneWay batch with server completion barrier, normalized per message 1.206 ± 0.0270 μs 1.200 ± 0.0223 μs 219 → 155 B/message
Client upload, eight 4 KiB items 94.91 ± 0.991 μs 95.13 ± 1.076 μs 36.40 → 36.41 KB/upload

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.

@SunSi12138
SunSi12138 marked this pull request as ready for review September 12, 2026 23:59
@SunSi12138
SunSi12138 merged commit bae9e50 into dev Sep 13, 2026
26 of 28 checks passed
@SunSi12138
SunSi12138 deleted the fix/release-stream-reservation-allocation branch September 13, 2026 00:04
SunSi12138 added a commit that referenced this pull request Sep 13, 2026
Merge the reviewed 2.0.0 performance corrections from dev into main.

The release branch tree is identical to the verified dev commit bae9e50; this merge adds main history only, with no source changes beyond the two reviewed performance corrections (#677, #678).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant