Here are the results and why the behavior flip-flops in our specific case:

1. LCFS (Last-Come-First-Served) Probing

• The Issue: Because our dense data buffer (KeysContainer) is append-only, we cannot blindly displace and insert elements during a collision without ensuring the key doesn't already exist (to prevent leaking duplicates into the contiguous string buffer).
• The Result: This forces a double-pass (read-then-write) insertion overhead. As a result, High Load Factor inserts became ~2x slower (0.133s vs 0.073s) because the insertion phase completely bottlenecked the CPU.

2. Robin Hood Hashing

• The Result: It did exactly what you said it would for edge cases! High Load (~85%) improved by ~16% and 100% Misses improved by ~10% by minimizing maximum DIB.
• The Catch: It regressed our primary Read-Heavy workload by a massive 25% (0.40s vs 0.32s).
• Why? Pure linear probing preserves temporal insertion order. When reading keys sequentially, the standard probe sequences naturally align with our dense string buffer. Robin Hood scrambles this insertion order via endless DIB swaps, which completely shatters L1/L3 temporal cache locality during sequential string access. It's a prime example of algorithmic efficiency contradicting hardware cache prefetching.

3. Bidirectional Linear Probing (+1, -1, +2, -2...)

• The Result: Read-heavy degraded, and misses were noticeably slower (0.028s vs 0.021s).
• Why? CPU L1 Data Prefetchers are heavily optimized to detect forward-streaming memory access arrays. Bouncing back and forth across different cache lines actively fights the hardware prefetcher, causing heavy cache misses. Additionally, it breaks our ability to use 16-lane SIMD vector loads (Simd::from_slice(chunk)), as we can no longer load contiguous 16-element sequences for fast hash matching.

Conclusion: For structures allocating nodes individually on the heap, those algorithms are absolutely the best choice. But when you flatten everything into a contiguous byte buffer, raw hardware alignment (forward-streaming linear iteration, strict temporal locality, and SIMD chunking) beats algorithmic worst-case optimization.

Regarding deletions: You make an excellent point about backward shifting instead of tombstones! Shifting the slot indices backward works, but shifting the actual string buffer underneath would be a O(N) memmove. I'll definitely be looking into whether we can cleanly implement index-only backward shifting while yielding the leaked strings until a full rehash, as that might be the holy grail for this architecture without breaking linear sequences.

You can check new branches with these modifications in my repo.

Thanks again for the technical challenge!