Performance and benchmarks

What the benchmarks measure and how to run them

Processes mapping the same region access the same memory pages. Zinc adds no serialization or data copy to that access. Reads and writes still cost memory bandwidth, page faults, and cache coherence; notification adds synchronization costs.

Criterion benchmarks

cargo bench -p zinc-core --bench latency
cargo bench -p zinc-core --bench throughput
cargo bench -p zinc-core --bench ring

Benchmark	Work measured
create_open	Create and drop, or open and drop, a one-page region
latency/thread_ping_pong	A notification request and reply between two threads using separate regions
write	Fill a mapped buffer and read back its first byte
notification_fast_path/same_thread	Notify and consume the pending change on the same thread
ring/push_pop	Push and pop one queue value
ring/contention	4096 values sent by contending producers to one consumer, including thread startup

The Linux notify/wait roundtrip target is under 5 microseconds. There are no checked-in results from the corrected ping-pong benchmark confirming that target. Measure it on the hardware and scheduling setup you plan to use. Criterion’s timing estimates are not per-message P50/P99 latency histograms.

On macOS, the sleep fallback trades idle CPU use for scheduler-dependent wake latency. Its results should be measured separately from Linux futex results.

Verify shared access

The Rust/Python interop test creates a region in a Rust process, writes known bytes, and reads them from Python while the creator remains alive:

cargo build --release -p zinc-core --lib --example interop
python3 -m pytest adapters/python/tests -q

Virtual pointer addresses do not need to match across processes. Each process can map the same backing pages at a different virtual address. Shared mutations, rather than equal addresses, demonstrate that the views refer to the same storage.

Comparison examples

cargo run --release -p zinc-core --example unix_sockets
cargo run --release -p zinc-core --example mmap
cargo run --release -p zinc-core --example grpc
cargo run --release -p zinc-core --example redis

These programs compare selected data-access and transport workloads. They retain the fastest of five samples and alternate execution order. Warmup touches mapped pages before timing. Treat the fastest sample as a best observed run, not a guarantee or a tail-latency measurement.

The shared-memory write loops fill the buffer and inspect one byte through another mapping in the same process. They do not measure a complete payload read in a second process. Socket and Redis paths move payload bytes, so their throughput numbers represent different work.

The examples report a warmed-up thread notification roundtrip. The raw mmap example uses the core notification functions to compare the same wait protocol.

The grpc example encodes protobuf over length-prefixed TCP. It does not implement HTTP/2, gRPC framing, or a gRPC client/server. The redis example needs a server on 127.0.0.1:6379.

The first page contains the header and padding; usable data starts at the next page boundary. Region creation and mapping costs are excluded from the timed write loops.

Recorded example output

These images are historical runs on the MacBook Pro described by the original benchmark documentation. They predate the corrected Criterion latency benchmark and should not be used to claim its current latency.

The pointer, capacity, notify, and wait paths contain no heap allocation in Zinc’s core implementation. Create and open allocate handles and make mapping syscalls. No heap-profiler results are checked in.