Repository navigation
Clarify zero copy semantics #56
Description
It’s unclear from the readme to what extend zero copy actually holds true. By my understanding, protobuf uses varints to encode any integers, which I would consider not to be zero-copy since we need to read up to 10bytes per integer in order to know offsets of other elements. It would be great if the readme explained that behavior and also when this resolution happens. Lazily when requesting to read certain parts? Eargerly (doesn’t seem zero copy either as the tree of messages would need to eagerly need to create a mask of offsets)?
Activity
dezyh commentedon Apr 21, 2026
I just want to add that prost supports bytes which is meant to provide zero-copy decoding for
bytefields in protobuf messages. I think this repo should try benchmarking with that too for a more fair benchmark.For example, running the prost benchmarks locally with `bytes` generation enabled
iainmcgin commentedon Apr 22, 2026
@brancz "zero copy" in the README is shorthand for the payload bytes of length-delimited fields are not copied from the input buffer into owned Rust types during decode. Varints, tags, and the fixed-width scalars are read, not copied in the memcpy sense. If that distinction would be clearer in the README we can tighten the wording — the claim we're making is narrower than "nothing is read from the input," and we don't want it to read as if it were.
What a view does avoid
A view is a borrow over the input buffer. For every length-delimited field, a view stores a slice into the original bytes:
stringfield →&'a str(UTF-8 validated once, no allocation)bytesfield →&'a [u8]message→SubMessageView<'a>(another borrow, no recursion into owned types)repeated T(packed or otherwise) →RepeatedView<'a, T>— an iterator-style wrapper over a slice of the input; elements are lazily materialized on.iter()map<K, V>→MapView<'a, K, V>— same idea; the map is walked, not builtThe result is that
decode_viewon a typical message does zero heap allocations, makes one linear pass over the wire format to record per-field slice offsets, and defers all per-element decoding to the caller. TheMessageViewtrait is the contract.What a view cannot avoid
Protobuf's wire format is not a memory layout, so some re-encodings are inevitable:
int32,fixed64,bool, etc.) are decoded eagerly during the scan, because there's nothing meaningful to borrow — they are already their target Rust type. Forfixed32/fixed64/sfixed*/float/double, this is a small-constant byte swap on big-endian hosts and a pointer-read on little-endian; there is no "zero copy" representation for these that would also be correct cross-platform.stringfields. A view holds&'a str, not&'a [u8], so we check once that the bytes are well-formed UTF-8. That is required by the protobuf spec and by Rust'sstrinvariant — no encoding lets us skip it without giving up one of the two.The scan itself is eager (not lazy), because the per-field offset table is what makes subsequent field access O(1) without rescanning. A fully lazy design would push that cost onto the first field access instead, which is a different trade-off; buffa does not take it.
Re: prost's
bytesfeature: Fair point @dezyh — we should benchmark prost with itsbytes::Bytesfeature enabled, both for completeness and because it's the closest prost analogue to what a view does forbytesfields. We've now done that in PR #61. The newprost (bytes)benchmark variant appliesprost-build::Config::bytes(["."])(substitutingbytes::Bytesfor everybytesfield) and decodes frombytes::Bytesinput, which is what actually exercises prost's zero-copycopy_to_bytesslicing path. The benchmark suite also now includes a deliberately bytes-heavyMediaFramemessage (primarybytes body+repeated bytes chunks+map<string, bytes> attachments) so the feature has something to work with.Raw throughput (MiB/s, higher is better; Intel Xeon Platinum 8488C,
task bench-crossin Docker;prost (bytes)deltas are relative toprost,buffa (view)deltas relative tobuffa owned):Observations:
prost (bytes)tracks default prost within noise on the larger messages and is ~10% slower onApiResponse. The slow-down onApiResponseis real: the proto message is small (~128 bytes/payload) and per-message fixed cost dominates, and enablingbytesresults in extra work for each message decode. Specifically, the atomicfetch_add/fetch_subaround eachpayload.clone()plus theBytesAdapter-generic codepath run even if there are nobytesfields. This adds up to nontrivial overhead without any zero-copy payoff to offset it. On larger single messages that overhead is a smaller fraction of the total decode cost (which explains the results forLogRecord/GoogleMessage1), and with deeply nested small messages likeAnalyticsEvent, the overheads makebytessignificantly worse (~24% slower here).On
MediaFrame,prost (bytes)is ~2.4× faster than default prost. This is exactly the payoff the feature advertises — the primary body, the chunks, and the attachments are all sliced from the input buffer rather than copied into freshVec<u8>s. This overcomes the overheads seen for the other message types that don't contain bytes fields.buffa views remain ~3× faster than
prost (bytes)onMediaFrame. To explain where the remaining gap comes from, we ranperf staton a native--measurement-time 6run of each variant onMediaFramedecode. Sample results:prost (bytes)closed the cache-miss gap — L1-dcache misses drop 113 → 5, which is the allocator traffic from cloningbytespayloads disappearing. But it still runs 2.8× more instructions per message than views: ~3k instructions per message is spent onStringallocation forframe_idandcontent_type, UTF-8 validation of those strings, theHashMap<String, Bytes>theattachmentsmap still builds (with hashed + heap-copied keys), and theVec<Bytes>thechunksfield still collects. Views skip all of it: the two strings stay&'a str,attachmentsis aMapView<'a, &'a str, &'a [u8]>that walks the input lazily on iter, andchunksis aRepeatedView<'a, &'a [u8]>.So
prost (bytes)and buffa views are solving different (overlapping) problems:.bytes(["."])is the correct prost feature for "don't copy bytes payloads", and it delivers cleanly on that. Views go further by not building the owning Rust collections for strings, maps, and repeateds either. When those fields aren't in your schema, the two should converge; when they are, the gap is what we see above.benchmarks: add prost bytes-feature variant + MediaFrame for zero-cop…
brancz commentedon Apr 24, 2026
I think this could be even clearer. It’s starting to make sense though, the point is that the input buffer never gets copied (hence zero copy), but it’s not zero-heap-allocations since the offset mask still needs to be computed.