nx_commitbench.nx

nx_commitbench.nx -- IS ss_commit_deferred WORTH ADOPTING? MEASURE BEFORE MIGRATING. WHY. ss_commit fsyncs the segment AND the directory on every call, so a logical transaction that appends N rows pays N durability barriers. ss_commit_deferred exists to make that ONE barrier -- it has existed since 2026-08-01, and as of 2026-08-07 NOTHING CALLS IT (debt 1786111613). The obvious move is to go adopt it everywhere. The disciplined move is to find out what it buys first: an unmeasured migration across a shared store is a lot of risk for a number nobody has. ★CORRECTNESS IS MEASURED ALONGSIDE SPEED, NOT AFTER IT. Both arms are counted for surviving keys, because a faster arm that loses rows is not faster, it is broken -- and ss_commit_deferred's own header states the honest bound it trades: after it returns the data IS VISIBLE (segment written, manifest renamed), only DURABILITY ACROSS POWER LOSS is deferred to the caller's ss_sync_now. So the row counts MUST match; if they ever do not, the deferred path is not what it claims. ⚠WHAT THIS CANNOT MEASURE, STATED SO THE NUMBER IS NOT OVERSOLD: it cannot measure the crash window. Arm B is exposed between its last deferred commit and its ss_sync_now, and no benchmark on a running host can price that. The speed number is real; the risk it buys is a judgement call that belongs to whoever adopts it, per-caller. usage: nx_commitbench [n] default 40 commits per arm license_tier: ORIGINAL No hw writes (Rule 26). expect_exit: 0