Phase B: Record Layer

Part of the hcloud-rebench-20261014 campaign.

Eight pkg/recordlayer benchmarks in three trees, counterbalanced. This separates two changes: the read-path parity work (record loads switched to Java’s whole-record range reads) and the allocation work that followed it.

Arms

All three trees ran byte-identical benchmark source (pkg/recordlayer/benchmark_test.go, harness d94b4c61377d173b7c6884fde426a227dab0f0bb; see campaign-harness.md), so differences come from the production code. final/before is the allocation work plus later changes; final/legacy is both changes together.

Environment and design

• The host and CPU groups are those of the phase A client run: Hetzner ccx43, fdbserver on CPUs 2–7, the benchmark process on 8–15 in a network namespace reaching the server over a veth pair. Here the single fdbserver 7.3.77 process used the memory engine, single redundancy.
• Per case: 6 balanced blocks over the three arms (seed 641101, every order once). One fresh process per arm and block, running the benchmark three times (-test.count=3): read benchmarks for 3 s each, write benchmarks for exactly 1,000 operations (SaveRecord, SaveRecordWithIndex, SaveSplitRecord insert IDs 0–999 into a freshly cleared subspace). 18 samples per arm and case, 432 in total. The cluster’s user keys were cleared before every process.
• Estimand: the geometric mean over blocks of each block’s arm ratio, using each process’s median of its three repeats, with a nominal 95% percentile bootstrap over blocks (20,000 resamples, seed 391706). Absolute values are the median over blocks of those process medians.
• ns/op is testing.B’s mean time per operation, not a percentile; B/op and allocs/op are Go heap allocations per operation.
• Workloads: SaveRecord and SaveRecordWithIndex save one small Order per transaction (with a VALUE index for the latter); SaveSplitRecord saves one ~250 kB record (three chunks); LoadRecord loads one record; ScanRecords/ScanRecordsSplitVersioned scan 100 records (the latter in the SQL default layout: split records with inline versions); ScanIndexRecords/serial and /pipelined scan 1,000 records through a value index, loading each record serially or with the production pipeline.

Results

Final vs before: the allocation work

Ratio final/before, nominal 95% interval.

Final vs legacy: both changes together

Ratio final/legacy, nominal 95% interval. The legacy tree predates the read-path parity change.

Absolute values

Median over blocks of each process’s median of its three repeats.

Interpretation

Measured:

• The allocation work cut allocations in every case. allocs/op fell 11–37% from before to final, most in the index scans (ScanIndexRecords/pipelined 0.627, /serial 0.651) and LoadRecord (0.793). B/op fell 9–25% except for SaveSplitRecord, whose ~1.6 MB per operation is dominated by the record itself (0.998).
• Time changed little. Only LoadRecord (0.978), ScanRecordsSplitVersioned (0.976) and ScanIndexRecords/pipelined (0.972) have intervals entirely below 1, about 2–3% faster. The other five include 1.
• The parity change dominates the index scans’ time. Compared with legacy, final is 48% slower on the serial index scan (1.477) and 14% slower on LoadRecord (1.138), but 35% faster on the pipelined index scan (0.647). The absolute medians put the step between legacy and before, i.e. on the parity change: serial 171 → 249 ms, LoadRecord 661 → 767 µs, pipelined 66 → 44 ms. Those legacy-to-before figures are ratios of medians, not paired estimates with intervals.
• Allocation work recovered most of the parity change’s allocations but not its time. On the serial index scan, parity raised allocs/op from 41,250 to 75,140 and the allocation work brought it to 48,917, while time stayed at about 247 ms.

Not explained by this data:

• The pipelined index scan got 34% faster with the parity change here, while the 2026-10-12 parity report measured +3% for the same change on a workstation (FoundationDB in Docker, no network namespace). A plausible difference is that whole-record range reads overlap better under this environment’s round-trip time, but that was not measured or profiled.
• Why LoadRecord is still 14% slower than legacy after the allocation work. The parity report attributes the extra work to reading and validating the whole record subspace instead of a point read; this run did not profile it.

Limits

• Same single host and veth path as phase A, one fdbserver process, single redundancy, memory engine: no replication, no network hop between storage servers, no disk. Each benchmark runs one operation at a time.
• testing.B reports means; there are no latency percentiles here.
• Six blocks give limited resolution; intervals are nominal, per case and metric, with no multiplicity correction and no aggregate across cases. SaveRecord’s final/legacy interval is wide because one block’s ratio was 1.36; its leave-one-block-out estimates range 1.005–1.073.
• Case labels in the aggregate CSV were reconstructed. A loop variable in the campaign runner shadowed the case key, so the runner wrote a CPU field name as every row’s case in metrics.csv (fixed in tools/benchcampaign/singlenode/bench_runner.py, with a regression test). The per-run directories kept the correct case, and the analyzer reparses the raw benchmark output. The 432 labels were restored from the pinned plan in a separate working copy; no measurement was repeated or changed.