view: zero-copy Bytes in to_owned via slice_ref of source buffer#74
Merged
view: zero-copy Bytes in to_owned via slice_ref of source buffer#74
Conversation
Adds MessageView::to_owned_from_source(Option<&Bytes>) so view→owned conversion can produce bytes::Bytes fields via Bytes::slice_ref (refcount bump, no copy) when the source buffer is supplied. OwnedView::to_owned_message now routes through this with its retained buffer, recovering the headline zero-copy benefit of #51 on the view→owned path. Fixes #52.
|
All contributors have signed the CLA ✍️ ✅ |
4 tasks
…ce sig The previous ::bytes::Bytes is an absolute crate path, requiring every consumer crate to depend on `bytes` directly. The conformance crate doesn't, so its build broke. Generated code must reference bytes via buffa's re-export, same as ::buffa::bytes::BufMut elsewhere.
rpb-ant
approved these changes
Apr 28, 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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Fixes #52.
Problem
PR #51 backed
Any.value(and any field inbytes_fields) withbytes::Bytesso cloning is a refcount bump. But the view→owned path — which production decode pipelines typically hit — was still emittingBytes::copy_from_slice(self.value), allocating and copying just like the old.to_vec().Approach
Rather than threading a
&'a Bytesthroughdecode_view(which doesn't compose withOwnedView<V>— theByteshandle moves intoselfafter decode, so a stored reference would dangle), this passes the source buffer at conversion time:MessageView::to_owned_from_source(&self, source: Option<&Bytes>) -> Self::Owned, with a default impl delegating toto_owned_message(so hand-written impls are unaffected).buffa::view::bytes_from_source(Option<&Bytes>, &[u8]) -> Bytes: returnsBytes::slice_refwhen the slice lies within the source (pointer-range check mirroringslice_ref's precondition),Bytes::new()for empty, elsecopy_from_slice. Slices outside the source (e.g. on a manually-constructed view) fall back to copy rather than panic.to_owned_message()now callsto_owned_from_source(None); the new method body emitsbytes_from_source(__buffa_src, ...)forbytes_fieldsand recurses into nested/repeated/oneof/map message values withto_owned_from_source(__buffa_src).OwnedView::to_owned_message()now callsto_owned_from_source(Some(&self.bytes)), so the'staticwrapper gets zero-copy automatically.No decode-path changes, no view-struct field additions.
Tests
bytes_from_source(None, in-range, out-of-range, empty, full-range).Anyvia both the direct trait path andOwnedView.buffa-testcoverage for repeated/optional/oneof/nested-message bytes shapes underuse_bytes_type().Out of scope / follow-ups
map<K, bytes>values are stillVec<u8>regardless ofbytes_fields(pre-existing;map_to_owned_exprhard-codes.to_vec()).string_fieldssuggestion is left for later.