perf(rust): coalesce intercepted HTTP response chunks - #2717
Open
mohamedmansour wants to merge 2 commits into
Open
mohamedmansour wants to merge 2 commits into
mohamedmansour wants to merge 2 commits into
Conversation
Poll bounded read-ahead alongside each pinned response acknowledgement without spawning a producer or changing WebSocket framing. Preserve cancellation, byte and error ordering, and document the raw-byte memory budget. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
🟡 Changes recommended
Fix the compile-blocking response-body ownership error before approval.
Get a fresh assessment by requesting another Copilot review.
Pull request overview
Improves Rust HTTP response forwarding by coalescing small chunks with bounded read-ahead.
Changes:
- Adds bounded response buffering.
- Integrates coalesced forwarding with cancellation handling.
- Adds forwarding and regression-test coverage.
File summaries
| File | Summary |
|---|---|
rust/tests/http_response_forwarding_test.rs |
Tests buffering, failures, cancellation, and byte preservation. |
rust/src/copilot_request_handler/http_response_reader.rs |
Implements bounded response buffering and error handling. |
rust/src/copilot_request_handler.rs |
Integrates coalesced forwarding; contains a critical ownership error that prevents compilation. |
Review details
- Files reviewed: 3/3 changed files
- Comments generated: 1
- Review effort level: Lite (auto)
Note
Copilot is running an experiment and ran this review at Lite.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Keep the remaining protocol regressions on the current-thread runtime while exercising real HTTP forwarding across two worker threads. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Contributor
Author
|
@stephentoub can you please look at this perf improvement please, found by profiling |
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
When
ClientOptions.request_handlerintercepts HTTP traffic, each small response fragment waits for a separate runtime acknowledgement. Bursty responses generate too many sequential RPCs. The default inference path is unaffected.Solution
Read ahead while the current write awaits acknowledgement, combining available HTTP bytes into chunks up to 32 KiB. Flush without waiting to fill a chunk, preserving byte order, cancellation, and error handling. WebSocket messages remain unchanged.
Two reusable buffers cap raw forwarding storage at 64 KiB per exchange, excluding the current source frame, source internals, and RPC serialization. No new tasks, dependencies, or parallel data RPCs.
Performance
Median results through the real SDK and local HTTP, comparing
0dd9d43withe5f719f:For the 1 KiB burst, allocation operations fell 61,189 → 5,295. Tradeoffs: first-byte latency 1.040 → 1.121 ms and peak live heap 2.27 → 2.37 MB. Heap/allocation measurements include SDK and synthetic peers, not RSS.
Five alternating pairs on Apple M4 Pro, macOS 26.6.2, Rust 1.94.0 release. Timing binaries were uninstrumented; allocations measured separately. Sparse streaming is essentially unchanged, and large-fragment timing ranges overlap. Shared-host results are workload-specific, not model-generation speedups; artificial ACK timers exceeded the requested 2 ms.