perf: bucketed Dash with in-segment displacement -> O(1) segment-local eviction (NOT a memory lever)

[ELares]

Why (conditional — only if the memory re-measure shows we merely TIE at the floor and the mandate wants a LEAD)

The parked branch feat/285-bucketed-segments (commit ba149db) implemented the Dragonfly shape (4x14 buckets + 4 stash, two-choice, presence bitmask) but got 1-3 B/key WORSE than flat because its per-record split trigger fired before the segment filled, LOWERING the load factor. It implemented two-choice + stash but SKIPPED DISPLACEMENT — the cuckoo-lite trick the Dash paper credits for >90% load factor, and the exact fix the parked commit names as missing.

Change

• Add in-segment displacement: a second independent bucket choice + one-level kick (move an existing record whose alternate bucket has room, chosen via the membership bitmaps) instead of splitting when both b and b+1 are full.
• Combine with the 16-wide in-segment bucketing closer from the perf-findings (route within segment by spare hash bits) so the probe scan drops from 64 to a hashbrown-class 16-wide group (the parked branch's probes were -15-20%).
• Keep the one-line probe; verify under miri with the existing oracle parity tests.

NUANCE (rejects the wrong lever)

At 128B values with >16B keys, Dragonfly gets NO free-inline-key benefit — the tie is LOAD-FACTOR + value-bin dominated. So DISPLACEMENT (raises load factor) is the right lever; a fatter inline-key slot is NOT (it would REVERSE the shipped round-5 density win). Reject the inline-key-slot option.

Two-for-one

The same bucketed dash unlocks O(1) segment-local eviction (current IC eviction is O(N/CAP) and would LOSE a fair DF eviction h2h). Respect the ADR-0003 determinism constraint on victim selection.

Magnitude / risk

-5 to -15 B/key uniform at trough keycounts, targeting sub-178.6 uniformly. MEDIUM risk (a hasher call on the kick path + one guarded move).

Acceptance

A Linux memmodel sweep of the displacement-augmented branch across 700k/900k/1M shows uniform sub-178.6 B/key with no probe/qps regression past the DASHTABLE.md gate.

Part of the Dragonfly par-or-better epic #665.

[ELares]

Retargeted: displacement is NOT the memory lever (measure-first, 2026-07-15)

A fine keycount sweep (both engines, one env, artifact #675) + a memmodel decomposition settle it:

• The index SLOT cost is ~12-14 B/key reserved; organic fill slack adds only ~2-3. So displacement (which shrinks that slack by raising load factor) can save at most ~2-3 B/key.
• The IC-vs-DF memory window gap (~7 B/key at 550-800k) is OBJECT-ENCODING, not table load factor: DF's CompactObj inlines these short keys + bins the value exactly; IC fuses key+value into a jemalloc-rounded blob. Displacement cannot touch that.
• Also: the earlier IC@700k=173.4 was a transient; IC is FLAT 160-164, wins 850k-1M, and beats DF's worst case (164 vs 183). The memory 'loss' is a narrow ~4% short-key window (owner accepted it as honest).

So this issue is retargeted away from memory to its OTHER real value: O(1) segment-local eviction (IC's current eviction is O(N/CAP) and would lose a fair eviction head-to-head). That is a genuine win but was NOT one of the three measured Dragonfly losses, so it is DEFERRED (not in the current 'close the losses' scope). Kept open as a tracked improvement.

The object-encoding memory lever (inline short keys / size-class-aware blob padding) is the real path to a uniform memory lead if ever pursued; filed conceptually here for the record.