206 lines
6.6 KiB
Markdown
206 lines
6.6 KiB
Markdown
# roto
|
||
|
||
Zero-allocation Rust protobuf reader and writer.
|
||
|
||
## Overview
|
||
|
||
Instead of deserializing binary protobuf data into Rust structs, roto scans a message _once_ on
|
||
construction — recording the byte offset of each field — then reads fields on demand directly from
|
||
the original bytes. No heap allocation, no data copying, no full deserialization upfront.
|
||
|
||
Writing works the same way: you provide a fixed buffer and a builder writes fields directly into it,
|
||
returning a slice of the bytes written.
|
||
|
||
## Design
|
||
|
||
`protoc` generates a `CodeGeneratorRequest` message; `protoc-gen-roto` (in
|
||
`src/bin/protoc-gen-roto.rs`) reads this from stdin, generates Rust source files, and writes a
|
||
`CodeGeneratorResponse` to stdout. `protoc` then writes those `.rs` files to disk. The generated
|
||
files are included directly in the crate that uses the protobuffers.
|
||
|
||
Sample usage:
|
||
|
||
```
|
||
protoc -Iproto/ proto/hackers.proto --plugin=./target/debug/protoc-gen-roto --roto_out=src/
|
||
```
|
||
|
||
This will generate a file, src/hackers.rs.
|
||
|
||
## Generated code
|
||
|
||
For each protobuf message roto generates two types:
|
||
|
||
- **Reader struct** `MessageName<'a>` — borrows the original byte slice, zero-copy.
|
||
- **Builder struct** `MessageNameBuilder<'b>` — writes into a caller-provided `&mut [u8]`.
|
||
|
||
Nested message types are placed in a `pub mod message_name { ... }` module (snake_case of the
|
||
parent message name) within the same generated file.
|
||
|
||
## Sample usage
|
||
|
||
Given this proto definition:
|
||
|
||
```proto
|
||
message Hello {
|
||
string hello_world = 1;
|
||
message InnerWorld {
|
||
string thought = 1;
|
||
}
|
||
InnerWorld inner_world = 2;
|
||
}
|
||
```
|
||
|
||
### Reading
|
||
|
||
```rust
|
||
fn parse_proto(data: &[u8]) -> roto::Result<String> {
|
||
// Scan the data once, recording field offsets
|
||
let hello = Hello::new(data)?;
|
||
|
||
// String fields return &str borrowed from the original bytes (zero-copy)
|
||
let hello_world: &str = hello.hello_world()?;
|
||
|
||
// Nested message fields return &[u8]; construct the nested reader from those bytes
|
||
let inner_bytes: &[u8] = hello.inner_world()?;
|
||
let inner_world = hello::InnerWorld::new(inner_bytes)?;
|
||
let thought: &str = inner_world.thought()?;
|
||
|
||
Ok(format!("{} is about {}", hello_world, thought))
|
||
}
|
||
```
|
||
|
||
Fields absent from the binary data return `Err(roto::RotoError::FieldNotFound)`.
|
||
|
||
### Writing
|
||
|
||
Nested messages must be serialized into a scratch buffer first, then embedded as raw bytes in the
|
||
outer builder.
|
||
|
||
```rust
|
||
fn build_proto(buf: &mut [u8]) -> roto::Result<&[u8]> {
|
||
// Serialize the inner message first
|
||
let mut inner_buf = [0u8; 256];
|
||
let inner_bytes = hello::InnerWorldBuilder::builder(&mut inner_buf)
|
||
.thought("some thought")?
|
||
.finish()?;
|
||
|
||
// Build the outer message, embedding the serialized inner bytes
|
||
HelloBuilder::builder(buf)
|
||
.hello_world("some world")?
|
||
.inner_world(inner_bytes)?
|
||
.finish() // returns Result<&'b mut [u8]> — the written portion of buf
|
||
}
|
||
```
|
||
|
||
Builder methods consume `self` and return `Result<Self>`, enabling `?`-based chaining.
|
||
`finish()` returns `Result<&'b mut [u8]>` — a slice of the portion of the buffer that was written.
|
||
|
||
### Repeated fields
|
||
|
||
Repeated fields return a `RepeatedFieldIterator<'a>`. Each item yields `Result<(&[u8], WireType)>`.
|
||
|
||
```rust
|
||
let hello = Hello::new(data)?;
|
||
for item in hello.tags() {
|
||
let (value_bytes, _wire_type) = item?;
|
||
// decode value_bytes according to the expected wire type
|
||
}
|
||
```
|
||
|
||
## Runtime API
|
||
|
||
The core runtime in `src/lib.rs` provides:
|
||
|
||
- `ProtoAccessor<'a>` — scans a message's fields and reads values at recorded offsets.
|
||
- `ProtoBuilder<'a>` — writes fields into a provided `&mut [u8]` buffer.
|
||
- `FieldIterator<'a>` / `RepeatedFieldIterator<'a>` — iterators over fields and repeated fields.
|
||
- `Tag`, `WireType` — protobuf encoding primitives.
|
||
- `read_varint`, `write_varint`, `skip_value` — low-level wire-format helpers.
|
||
- `RotoError`, `Result<T>` — error type and alias.
|
||
|
||
## High-level design
|
||
|
||
On construction (`MessageName::new(data)`), the generated reader struct iterates the binary once
|
||
using `FieldIterator` and records the byte offset of each field's tag. Subsequent field accesses
|
||
call `ProtoAccessor::get_value_at(offset)` — no re-scanning. For repeated fields, the start and
|
||
end offsets of the field range are recorded to bound iteration efficiently.
|
||
|
||
## Benchmarks
|
||
|
||
Two benchmark suites share the same binary data files and the same four
|
||
measurement groups:
|
||
|
||
| Group | What is timed |
|
||
| --------------- | ------------------------------------------------------- |
|
||
| `shallow_parse` | Become ready to read any field (one scan / full decode) |
|
||
| `deep_parse` | Walk the full tree: Campaign → Operations → Hackers |
|
||
| `field_access` | Read individual fields on an already-parsed message |
|
||
| `iterate` | Count top-level and nested repeated fields |
|
||
|
||
### 1 — Generate the shared data files (do this once)
|
||
|
||
Data files are written to `data/bench/`.
|
||
|
||
```sh
|
||
cargo run --release --bin gen_bench_data -- --preset tiny
|
||
cargo run --release --bin gen_bench_data -- --preset small
|
||
cargo run --release --bin gen_bench_data -- --preset medium
|
||
cargo run --release --bin gen_bench_data -- --preset large
|
||
```
|
||
|
||
For even larger inputs use `--preset huge` (~500 MB) or set the knobs
|
||
directly:
|
||
|
||
```sh
|
||
# ~50 MB: 500 operations × 100 KB stolen_data each
|
||
cargo run --release --bin gen_bench_data -- --ops 500 --stolen-kb 100 --output data/bench/50mb.pb
|
||
```
|
||
|
||
### 2 — Rust benchmark (criterion)
|
||
|
||
```sh
|
||
cargo bench --bench hackers_bench
|
||
```
|
||
|
||
HTML reports are written to `target/criterion/`. Run a single group:
|
||
|
||
```sh
|
||
cargo bench --bench hackers_bench -- shallow_parse
|
||
```
|
||
|
||
### 3 — C / upb benchmark
|
||
|
||
Requires protobuf ≥ 21 with `protoc-gen-upb` (ships with modern `protoc`).
|
||
|
||
```sh
|
||
cd upb_test
|
||
make # compiles hackers_bench from the pre-generated upb files
|
||
./hackers_bench
|
||
```
|
||
|
||
To regenerate the upb C files from `proto/hackers.proto`:
|
||
|
||
```sh
|
||
cd upb_test && make regen
|
||
```
|
||
|
||
### Interpreting the comparison
|
||
|
||
The two libraries have fundamentally different models:
|
||
|
||
- **roto `shallow_parse`** does one linear scan recording byte offsets — no
|
||
allocation, no field decoding. Subsequent field reads decode on demand at
|
||
the stored offset.
|
||
- **upb `Campaign_parse`** fully decodes the entire message tree into
|
||
arena-allocated structs upfront. Subsequent field reads are direct struct
|
||
member lookups (~1 ns).
|
||
|
||
The result: roto's parse is faster and allocation-free; upb's field access
|
||
after parsing is faster. For workloads that read every field the costs
|
||
invert; for workloads that read a handful of fields from large messages roto
|
||
wins.
|
||
|
||
## Literature
|
||
|
||
https://protobuf.dev/programming-guides/encoding/
|