Performance & Conformance

Note

This page is auto-generated from the live test + benchmark harnesses on each docs build (bench/gen_results_page.py, ADR-0032). It is the published response surface, not a hand-edited snapshot. All rates and latencies are absolute measured values, representative of the CI runner (shared-runner variance is real — read trends, not the third digit); the libtracer-vs-Zenoh charts below plot both engines on the same axes.

🤖 CI-generated on 2026-07-07 22:58 UTC · commit 6060f21 · run 28904373853 · runner Linux.

Cross-core conformance (every native core must agree byte-for-byte)

The shared conformance vectors are decoded+re-encoded by every enabled core; a DISAGREE fails CI (ADR-0028). Live driver summary:

• cpp: 28/28 vectors ok

• ts: 28/28 vectors ok

• rust: 28/28 vectors ok

• CONFORMANCE: PASS

In-process latency & throughput

Canonical points from bench_libtracer (the µs-latency / zero-copy thesis, ADR-0031):

path	p50 latency	mean	throughput
in-process (zero-copy dispatch)	240 ns	239 ns	4.5 M/s
in-process, zero-alloc loaned path	210 ns	215 ns	5.2 M/s
write-by-path (registry lookup)	291 ns	295 ns	3.6 M/s

Cross-core codec performance (decode→encode roundtrip, same v1 vectors)

Every native core (cpp-core / ts-core / rust-core) runs the SAME per-vector decode→encode roundtrip over the shared v1 conformance vectors (ADR-0032 lang axis, #96), so this is a like-for-like codec surface across implementations. Figures are the median across all v1 vectors (one decode + one encode == one roundtrip); a core whose toolchain is absent in this build degrades to a note.

core	throughput (median)	p50 latency (median)	mean (median)
cpp-core	2.2 M roundtrips/s	465 ns	469 ns
ts-core	0.7 M roundtrips/s	1457 ns	1581 ns
rust-core	2.6 M roundtrips/s	410 ns	416 ns

libtracer vs Zenoh — measured, absolute

A side-by-side comparison against Eclipse Zenoh (zenoh-c 1.9.0, peer mode). Two surfaces: three in-process axes — subscriber fan-out, payload size, and topic count — and a network comparison over the real loopback kernel path. Both engines are built -O3 and measured in the same pass on the same runner, so the numbers are directly comparable on identical hardware. The charts plot absolute throughput / latency / bandwidth — libtracer and Zenoh as two series on shared axes — so you read the real numbers off the graph; there are no speed-up ratios.

Network throughput is charted against composition size K, because throughput here comes from batching, and the two engines batch differently. libtracer batches by composition: a composite endpoint’s value is a K-link rope already in memory, shipped as one datagram (send(iov) — one syscall for K values), so effective values/s scale with K at flat latency. Zenoh has no composite send; its throughput is the transport’s timer-batched put rate, independent of K — so it plots as a flat reference. (A single one-value-per-send rate would be the unbatched worst case for libtracer and is not the throughput path.) Network latency is the separate per-transport (UDP / TCP), single-value, two-process measurement — the same topology for both engines, so it is fair.

WebSocket and QUIC are not yet charted: libtracer’s WebSocket transport shows large single-run latency spikes under this bench (order-of-magnitude p50 jitter) that would make a published latency chart misleading, and QUIC needs the -DLIBTRACER_WITH_QUIC module (msquic + TLS). Full harness in bench/.

iBoth engines are built -O3 and measured in the same pass on the same runner, so this is like-for-like on identical hardware. Values are absolute and representative of the CI runner — read trends and orders of magnitude, not the third digit (shared-runner variance is real). No ratios: every point is a measured number on an absolute axis.

libtracer — inproc zero-copy dispatch Zenoh — zenoh-c 1.9.0, peer mode

sweep	system	point	throughput	bandwidth	p50 latency

**🤖 CI-generated** on 2026-07-07 22:59 UTC · commit [`6060f21`](https://github.com/avatarsd-llc/libtracer/commit/6060f214a13fab323692ed2869822a95512cdff2) · [run 28904373853](https://github.com/avatarsd-llc/libtracer/actions/runs/28904373853) · runner `Linux`.