Benchmarks

The reference implementation compared with FlatBuffers and Cap'n Proto on the same data. These numbers come from one machine and one run. Treat them as a measurement of this implementation, not of the format in general, and run them on your own hardware before relying on them. How we got to these numbers is in History.

Setup

To reproduce:

cargo bench -p graven-bench --bench codec
cargo run --release -p graven-bench --bin sizes
cargo run --release -p graven-bench --bin allocs

Scenarios

The same four messages are implemented in all three formats, and a test (crates/graven-bench/tests/equivalence.rs) checks that every implementation reads the same values for 20 random seeds per scenario.

Keeping the comparison fair

• Reused contexts. Graven reuses its Builder, FlatBuffers its FlatBufferBuilder (reset()), Cap'n Proto its scratch allocator.
• Same output contract. The graven write column hands out a borrowed slice, as FlatBuffers' finished_data() and Cap'n Proto's output Vec do. graven_owned returns an owned, reference-counted buffer per message; graven_batched packs messages into one buffer for sending.
• Lists. Cap'n Proto must know a list's length before writing it. graven in bank writes the list as a stream, without knowing its length; graven_known passes the length, as Cap'n Proto does.
• Strings. Graven validates UTF-8 on every read in its default mode. FlatBuffers' root_unchecked and Cap'n Proto do not. graven_trusted reads a message that was already verified, without validating again.
• Verification. FlatBuffers' verifier and Graven's verify walk the whole message before reading. Cap'n Proto checks lazily, while reading, and does not validate UTF-8, so its verified column is not the same amount of work.

Size

Bytes per message. Smaller is better.

Graven is smaller than FlatBuffers and unpacked Cap'n Proto everywhere. Packed Cap'n Proto is smaller for messages with many small integers, and pays CPU time to pack and unpack.

Allocations

Allocations per written message, after warm-up.

Time

Nanoseconds per message, median. Lower is better; bold is the fastest.

Writing

Only bank has a list whose length can be unknown; in the other rows the first column is the only Graven measurement.

Owned and batched messages:

An owned message pays an atomic reference count; batching amortizes it over many messages. A large owned message is also slower than a borrowed one because it needs fresh memory instead of rewriting the same cache-hot buffer.

Reading every field

Reading one field

Verifying and reading every field

The envelope

The optional envelope adds 24 bytes and a CRC32C over the whole message.

Verification does not touch payload bytes, so a 64 KiB chunk verifies in under 3 ns; the CRC reads all of them. For small messages the envelope costs about 10 ns on each side.

CRC32C throughput, hardware instruction against the portable software version (used without std):

Where Graven loses

• Size against packed Cap'n Proto for messages made of many small integers.
• Reading every field of frame/500 against Cap'n Proto: 2414 ns against 2296 ns, about 5%, within the noise of one run.
• Verified reading of large messages (bank/100, frame/500) against Cap'n Proto, whose check is lazy and skips UTF-8; against FlatBuffers' full verifier Graven is 6–10× faster.
• Writing a list of unknown length costs 1.4–1.7× a list whose length is known.