nordisk/knut

Benchmarking: nornir bench, not cargo bench

knut has exactly one benchmark suite and it follows the nornir contract (see znippy's .nornir/benching.md for the original rationale):

• Each bench is a struct implementing nornir's Bencher trait, registered with register_bench!; inventory collects them at link time.
• xtask/examples/nornir-bench.rs::main() is nornir::bench::api::run_main_json() — every registered bencher runs and one BenchRun JSON line goes to stdout, ready for the warehouse.
• xtask/benches/nornir.rs is a [[bench]] shim that #[path]-includes the example, so cargo bench -p xtask runs the identical suite.

Run

cargo run -p xtask --release --example nornir-bench   # canonical (JSON to stdout)
cargo bench -p xtask                                  # same suite, familiar verb

Suite

Latest run

100k-row workloads, --release, --features skade, 32-core machine (median of 4 runs; 2026-06-11). Each bencher is single-shot per run, so nanosecond in-memory micros (bifrost_fabric, merge_property_groups) read as multi-G rows/s — they bound the pure mutation/merge cost, not an IO path.

The zero-copy in-memory Arrow bridge runs ≈1.96× the parquet temp-file path (5.37 M vs 2.75 M rows/s) — the headroom a direct in-memory hand-off reclaims over serializing through a parquet round-trip. (These numbers predate the workspace unifying on Arrow 58, when the bridge became a plain identity clone(); see reasoning.md.) Runs persist to the workspace bench_runs Iceberg table via nornir bench run knut (the --features skade opt-in is passed as NORNIR_BENCH_FEATURES=skade).

FalkorDB boundary cost (measured live, 2026-10-19)

Live numbers against a real FalkorDB (100k rows × 3 cols, medians of 5): response_to_batch_auto decodes at 7.0–7.6M rows/s (13–14 ms) — the client-side decode is NOT the results-back bottleneck. The RESP wire (server serialize + client parse of the same reply) costs 150–162 ms, ~11× the decode, with server-side result production another 42–44 ms. So the honest budget at this boundary is the wire representation, not convert.rs; a column-parallel decode was prototyped, proven zero-loss and dropped — its win ceiling was the 13 ms.

DB-free arm numbers (dwarf, 6-core Ryzen 5 7535HS, container, nice -19, 2026-10-19; medians over interleaved runs — single-shot ~20 ms arms on this shared box carry ±30% noise): falkor_bulk_encode ~10M entities/s both before and after the blob presizing (the presize is proven structurally — the estimate is a tested upper bound, so the one up-front allocation is the only one — but at 200k entities the saved reallocs sit inside the box noise); falkor_decode ~4.2–4.6M rows/s (container; ~7.0–7.6M measured live on the measurer's box); falkor_parallel_dispatch speedup_x ~12 on 12 logical cores, unchanged across the buffer_unordered → gatling::io::run swap (same semantics, proven by the peak-in-flight test); cypher_render ~1.8–2.2M rows/s on this host (the 3.09M in the table above is the older 32-core row).

--compact assessment — BUILT AND MEASURED 2026-10-20: keep it OFF. The flag is implemented end to end (FalkorExecutor::with_compact(true): graphar-flight/src/compact.rs rebuilds the exact verbose Value tree from the type-tagged compact reply, id→name catalogs from CALL db.propertyKeys()/db.labels()/db.relationshipTypes() refreshed on miss, so the ONE existing decoder runs either way — zero-loss pinned live by tests/integration_compact.rs on scalars, lists, maps, points, nodes and edges, plus DB-free pins in compact.rs; red-first: the live parity test fails with the raw compact reply handed to the old decoder). The redis crate (0.29) parses the compact wire fine. The measured verdict is a REGRESSION on this client stack (release, dwarf, 100k rows, medians of 5, live server):

Why: scalar rows carry NO repeated names in verbose RESP2, so compact's [type_id, value] framing is strictly more RESP tokens (every Int cell becomes a 2-array) — the shape the 150–162 ms was measured on cannot win by construction (the 146.8 ms verbose arm here reproduces that number). On entity rows the dropped name strings do shrink the wire, but the extra per-cell arrays cost more in the redis Value parse than the names save, and the zero-loss contract (equal RecordBatches) adds the verbose-tree rebuild on top. with_compact ships OFF by default; a direct compact→Arrow decoder with its own entity rendering could revisit the entity shape, but that changes the produced batches — a different contract.

Ingest lanes for scale (same live session, 200k rows): GRAPH.BULK 1.3–2.6M nodes/s vs UNWIND ~14.5k nodes/s; keyed edges (insert_edges MATCHing both endpoints on _gar_id) ~2.7k edges/s — the slowest lane in the pipeline by ~5×.

Keyed-edge lane, re-measured 2026-10-20 (dwarf, container, live server — graphar-falkordb/tests/live_keyed_edges.rs):

• The 2.7k edges/s DID have the _gar_id index (the measuring harness created it). Without it the plan is a per-row Node By Label Scan: ~17 edges/s at 100k nodes, measured live. The loader now creates the endpoint key indexes ITSELF before the first window (insert_edges*, serial and _par; composite keys via one idempotent per-property create_index each — FalkorDB coalesces them into the label's index and the composite MATCH plans Node By Index Scan, probed live), so the 17 edges/s footgun is gone by construction. Red-first: a fresh keyed load on a virgin graph listed NO index before the fix, does after.
• Edge windows now ride a CYPHER rows=[…] parameter into a constant UNWIND $rows … MATCH … CREATE body (same row maps, same writer — zero-loss pinned by the literal↔param oracle param_windows_store_identical _graph and the exact-triples robot suite). The body is parsed/planned once and every later window hits the plan cache. Interleaved A/B on the same box (100k chain edges, _gar_id indexed, debug harness): literal 2472 / 2532 edges/s, param 2911 / 2699 edges/s — a consistent but modest +9–15%; the param value parse still dominates the window. (Same-code runs ranged 2.5k–11.5k edges/s across the day on this shared box, so the interleaved pairs are the honest comparison; release-profile spot check: 3334 edges/s.) The remaining big lever for initial loads stays GRAPH.BULK.

Fixtures are synthetic and tempdirs live in /tmp — local disk, never the T9 USB drive (external IO would skew throughput). Container-bound performance (FalkorDB ingest, Spark reads) lives in the #[ignore] integration tests, not in the release gate. The skade bencher is opt-in (--features skade) so the default release gate stays free of skade's heavy arrow-58/iceberg tree.

Host row: oden (2026-07-22)

oden is a NEW host row — a Threadripper PRO 3975WX, 32 physical cores, SMT off, 499GB RAM. It is not the loki 12 cores machine the numbers above were taken on; the two must never be merged into one table.

NORNIR_MACHINE=oden, --release, --features skade.

knut.iceberg_pushdown_read — the Iceberg full-width-scan fix

1000000 rows x 11 columns across 4 data files; the mapping reads 2 columns.

Plan-time data skipping (plan_stats, metadata only — no data file opened): files_baseline 4 → files_planned 1 (files_skipped 3); rows_baseline_planned 1000000 → rows_planned 250000.

knut.doput_dispatch — the Flight SQL DoPut fix

40000 vertices, FalkorDB on loopback, concurrency 32.

speedup_x 1.19, doput_vs_inprocess_x 0.985.

The honest reading: the Flight transport costs ~nothing (DoPut is within 1.5% of the in-process call), so the standing "DoPut is ~100x slower than in-process" note does not reproduce. FalkorDB's per-graph write serialisation is the ceiling (≈28000 nodes/s); an UNWIND window sweep from 512 to 40000 rows moved it under 10%. The client-side pipelining win is a ROUND-TRIP win and shows up when FalkorDB is a network hop away — which is what the DB-free knut.falkor_parallel_dispatch arm models (29.5x at a simulated 500us RTT on this same host), not on loopback.

korp-collectors cross-reference

Not a knut arm, but taken on the same host in the same session: collectors_registry/sample_sweep — 58 collectors resolving their offline-safe samples, 113.85 us, 224.89 MiB/s.