Repository navigation
perf(net): avoid the forwarding coroutine in WriteAll - #24
Merged
Merged
Conversation
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars.
|
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.
TcpStream::WriteAllallocates a forwardingWriteSomecoroutine for each write chunk. Await the existing plain write operation or TLS writer directly in the loop, removing that frame while preserving partial writes, error handling, stream ownership and TLS encryption. Public interfaces and buffer capacities are unchanged.Validated with 26 Bycorf runtime/network tests and four Lavik E2E tests (large requests/TLS, fragmented replies, native replication and remote GET), all passed with zero skips. Release disassembly confirms that
WriteAllcallsTcpStream::WriteSomebefore this change and no longer does afterward. clang-format 23.1.1 passes.Measured with Lavik PR #388 commit
8be6211, changing only this Bycorf function from pinned revisionedb5804: Azure L16aos_v4 server (16 vCPU), separate L32aos_v4 load generator, 32 client threads, 10M existing keys, 1 KiB values, SPDK storage and kernel TCP. Two reverse-order rounds, fresh fill per visit, 30s warmup; SET windows are 120s and GET windows 60s.Both rounds had positive throughput differences. These are small effects; two rounds do not establish sub-percent gains as statistically significant. Mean per-run SET P99.9 was 11.935→11.839 ms at 320 connections and 27.199→27.519 ms at 640. All command counts matched, GET had zero misses, and no connection errors or half-median throughput seconds occurred. No new object pooling or retained buffer capacity is introduced.