perf: avoid copying WebSocket deflate/inflate output - #1235
Open
pjfanning wants to merge 1 commit into
Open
Conversation
Motivation: PerMessageDeflate buffers the output of the Deflater/Inflater in a ByteArrayOutputStream and then calls ByteString.fromArrayUnsafe on toByteArray. ByteArrayOutputStream.toByteArray always copies the buffer, so every compressed or decompressed WebSocket frame pays a full copy of its payload. Modification: Add an internal ByteStringOutputStream that extends ByteArrayOutputStream and exposes toByteStringUnsafe, wrapping the internal buffer in a ByteString without copying when most of the buffer is used, and copying to a right-sized array otherwise so a large buffer is not retained by a small payload. Use it for the inflate and deflate paths in PerMessageDeflate, which allocate the stream per call and discard it immediately afterwards. Result: No copy of the payload per WebSocket frame when permessage-deflate is enabled, and no oversized buffer retained when a frame only fills a small part of it. Tests: - sbt "http-core/testOnly org.apache.pekko.http.impl.util.ByteStringOutputStreamSpec org.apache.pekko.http.impl.engine.ws.WebSocketServerSpec" - 51 tests succeeded - scalafmt --list --mode diff-ref=upstream/main - no files reported - sbt headerCreateAll - headers added for the new files References: None - the ByteStringOutputStream implementation is adapted from Apache Pekko gRPC (Apache License 2.0), apache/pekko-grpc#862
Member
Author
|
@mkurz does this look like a viable micro-optimisation on the per message deflate? |
pjfanning
added a commit
to apache/pekko
that referenced
this pull request
Aug 28, 2026
Motivation: `ByteStringBuilder` accumulates writes from `putByte`/`putBytes`/`putInt`/ `asOutputStream` into a temporary array and flushes it in `clearTemp`, which always does `java.util.Arrays.copyOf(_temp, _tempLength)`. On the final flush performed by `result()` that copy is avoidable: the buffer is not needed for further writes at that point, so every builder result pays a full copy of its tail chunk for nothing. Modification: Add a private `clearTempForResult` used only by `result()`. When more than half of the temp buffer holds data, the buffer is handed over to the resulting `ByteString1` instead of being copied, and `_temp`/`_tempCapacity` are reset so that a later write to the builder allocates a fresh buffer rather than mutating the bytes that were handed over. When only a small part of the buffer is used it is still copied, so a small result does not retain a much larger array. The mid-stream `clearTemp` calls made by `addAll` are unchanged, since the buffer is still reused there. Result: No copy of the tail chunk on `result()` for builders that are at least half full. A result produced by the hand-over path can be a non-compact `ByteString1`; that is copy-neutral, because a consumer calling `toArrayUnsafe` on it pays exactly the copy that used to happen inside `clearTemp`, and `ByteStringUtils.toProtoByteStringUnsafe` still takes its zero-copy `asByteBuffers` path for it. Tests: - `sbt "actor-tests/testOnly org.apache.pekko.util.ByteStringSpec"` - 218 tests succeeded, 0 failed - `ByteStringSpec` gains cases for the mostly-used, exactly-filled and small-write-in-a-large-buffer flush paths, that a returned `ByteString` is unaffected by later writes to the builder, and that the content is correct for every fill level from 0 to 200 bytes - `scalafmt --list --mode diff-ref=upstream/main` - no files reported - `git diff --check` - clean - Broader run of `actor-tests/testOnly org.apache.pekko.util.*`, the stream io/compression/framing suites and `actor/mimaReportBinaryIssues` was started but stopped before completing, so it is not recorded as a pass. MiMa is expected to be unaffected: the change adds one private method and alters no signature. References: None - follows the same no-copy approach as apache/pekko-http#1235
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
1 participant
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.
Motivation
PerMessageDeflatebuffers the output of theDeflater/Inflaterin aByteArrayOutputStreamand then callsByteString.fromArrayUnsafe(output.toByteArray).ByteArrayOutputStream.toByteArrayalways copies the buffer, so every compressed or decompressed WebSocket frame pays a full copy of its payload.Modification
Add an internal
ByteStringOutputStream(@InternalApi,private[http]) that extendsByteArrayOutputStreamand exposestoByteStringUnsafe:ByteString.fromArrayUnsafe(buf, 0, count)with no copy;The stream must not be written to or reused after
toByteStringUnsafe, which is documented on the method. Both call sites (inflateanddeflateinPerMessageDeflate) allocate the stream per call and discard it immediately afterwards.HeaderCompressionalso uses aByteArrayOutputStream, but it reuses one instance across frames viareset(), so it is left unchanged here.Result
No copy of the payload per WebSocket frame when
permessage-deflateis enabled, and no oversized buffer retained when a frame only fills a small part of it.Note that
toByteStringUnsafecan return a non-compactByteString1, so a consumer that callstoArrayUnsafe()on the result will copy - that is the same single copy as before, just moved, and it is avoided entirely for consumers that do not need an array.Tests
sbt "http-core/testOnly org.apache.pekko.http.impl.util.ByteStringOutputStreamSpec org.apache.pekko.http.impl.engine.ws.WebSocketServerSpec"- 51 tests succeeded, 0 failedByteStringOutputStreamSpeccovers the empty, exactly-filled, grown-buffer and small-write-in-a-large-buffer cases, including that the copied result is unaffected by later writes to the streamscalafmt --list --mode diff-ref=upstream/main- no files reportedsbt headerCreateAll- used to add the headers for the new files@InternalApi private[http]code and adds no public APIReferences
None - the
ByteStringOutputStreamimplementation is adapted from Apache Pekko gRPC (Apache License 2.0), apache/pekko-grpc#862