Run a Benchmark

Datum ships Criterion micro-benchmarks for all four operator areas and a set of head-to-head comparison runners that pit Datum against warmed Akka/Pekko Streams.

Criterion benchmarks (Datum only)

No JDK required. Run from the repo root:

cargo bench --bench push_baseline    # sanity baseline
cargo bench --bench source_flow      # Source/Flow operators
cargo bench --bench materialization  # graph construction, materialization, sink terminals
cargo bench --bench graph            # GraphDSL, fused executor, junctions
cargo bench --bench actor_ask        # ActorFlow::ask throughput, latency, timeout

Each bench produces an HTML report under target/criterion/<bench-name>/.

Datum vs. Akka comparison (requires JDK + sbt)

The comparison harness builds a Datum release runner and the matching Akka JMH benchmark, then renders a shared table. Each runner lives under benches/<area>_compare/:

benches/source_flow_compare/run.sh
benches/materialization_compare/run.sh
benches/graph_compare/run.sh
benches/actor_ask_compare/run.sh

The Akka side runs under fair JMH warmup (-wi 5 -i 5 -w 1s -r 1s). The Datum side adds a Datum CPU us/op column derived from /proc/self/stat — a process CPU time measurement that is deliberately separate from wall-clock. Some Datum wins come partly from busy-spinning while Akka parks; the CPU column makes that cost visible.

Reading the results

Current result tables live in roadmap/benchmarks/:

• source-flow.md — Source/Flow operators
• materialization.md — construction, materialization latency, sink terminals
• graph.md — GraphDSL, junctions, fused executor
• actor-ask.md — ActorFlow::ask ordered/unordered, timeout

The tables include both wall-clock (µs/op) and CPU (Datum CPU µs/op) columns. A path that wins on wall-clock but loses on CPU is spending that CPU on spin-polling. Datum reports it honestly rather than hiding it.

See roadmap/M1-v0.1.0-foundation.md for the apples-to-apples caveats and the per-operator coverage matrix.