When does a hash table choke?

A hash table's load factorα = items ÷ slots. The single number that governs how expensive lookups are. Keep it below about 0.7 for open addressing, or rehashing becomes cheaper than suffering the probes. α is items ÷ slots. With open addressingProbing: on a collision, scan forward (or quadratically, or via double-hashing) until you find an empty slot. One contiguous array, great cache behaviour — but α must stay below 1, and the probe count blows up before you get there., the average probes per lookup follow 1/(1−α) — the very same cliff as a queue near 100% busy — which is why tables resize around 70% full, long before they're "full". Separate chainingChaining: each slot holds a linked list of items that hash there. Allows α > 1, and lookup cost grows linearly — but pointer indirection kills cache locality. only sags, linearly.

items in a table ofslots.

load factor α = 0.75

5000×10×100×1000×
α 00.20.40.60000000000000010.8α 0.750.99
hitmiss / insert
8.5probes per miss

At α = 0.75, a failed lookup probes 8.5 slots on average. Push toward full and it runs off a cliff — the same 1/(1−α)² shape as a busy queue, only steeper.

2.5probes on a hit
8.5probes on a miss
0.75load factor α
Load factor αHit probesMiss probes
0.501.5
2.5×
0.702.2
6.1×
0.803
13×
0.905.5
51×
0.9510
200×
0.9950
5000×

For open addressing, the miss cost is the same 1/(1−α) cliff — squared, even — as a queue at high utilisation. That is exactly why hash tables grow and rehash around α ≈ 0.7, well before they're full. Chaining degrades gracefully (linear in α) but spends memory on pointers and loses cache locality. The same math as the queue cliff, a different domain.

based on hash table load factor · probes ≈ ½(1 + 1/(1−α))