Programming Fundamentals · Hashing & Caching: Space for Time

Hash Tables: Why Lookups Are Unreasonably Fast

Remember the foreshadowing in lesson one? Version B of “check the member list” used one line set.has(user)—list from 100 to 10 million people, time barely moved. We promised to unmask it in lesson five—today we take that “direct hit” magic apart: it doesn't scan; it computes.

Unmasking · it doesn't scan—it computes

Back to the organizing metaphor: searching a big drawer means flipping one by one because you don't know where things are. A hash table flips that completely—the moment you put something in, a fixed formula computes which bucket it belongs in; to look it up, run the same formula again and open that bucket. That formula is the hash function—a “locator formula”: no scanning, one step to where it is.

Hands-on · drop keys into buckets yourself

Below: 8 buckets numbered 0–7, and 6 names waiting to move in. Tap a name and watch three steps into a bucket: turn each character into its computer code and sum them, mod 8 (only 8 buckets), then fly into the computed bucket. Watch for: no “compare one by one” anywhere—the place is entirely computed.

Hash function (locator formula): name → number → mod 8 = bucket
 
 
 
Tap a name above to start · each name moves in once
Why is lookup just as fast? Because find and put use the same formula. Ask “Is 丽丽 in?”—the hash table doesn't walk the list; it recomputes on the spot: 丽丽 → 40058 → mod 8 = bucket 2, open bucket 2. Same with 6 people or 6 million—the formula's cost doesn't depend on how many names. That's the whole secret of “unreasonably fast.”
Plot twist · two names land in the same bucket

You may have noticed: 阿芳 and 丽丽 both land in bucket 2! That's a hash collision—only 8 buckets, countless names; collisions are inevitable. The most common fix is charmingly simple: hang a mini linked list in the bucket; newcomers line up on the chain (jargon: “chaining”). Tap the three buttons in order—watch for how many peeks a lookup takes.

 
 
Even after a collision, only 2 peeks. Direct to bucket 2 (not a scan), see 阿芳 on the chain (peek 1), then 丽丽 (peek 2)—still far faster than walking all 6 names. If buckets are too few and chains grow long, the table adds buckets and rehashes (resize): e.g. 8 → 16 buckets, recompute every name with the new formula so chains shrink again. That's “trade space for time”—spend a few more buckets, buy back direct-hit speed.
Final duel · walk the list vs direct hit

Now scale the data and race both lookup styles head-on. Pick a size, hit Race. Watch for the counter on the right: no matter how long the left side scans, it always stops at 1–2 peeks.

Data size:
🗄 Walk the list (linear lookup)
Peeks 0
 
🗃 Direct hit (hash lookup)
Peeks 0
 
Animation is slowed on purpose—the real gap is even wilder
Its real form in the AI world

The hash table may be the structure serving you most each day—it just stays backstage. These four scenes all use the same move: “compute the place, one-step direct hit.”

🧰

Set & dictionaries

Lesson-one version B's Set, Python's dict, JS's Map—every “get by key” container in a language has a hash table inside.

🔑

Cache keys

A cache must answer “have we computed this?” in milliseconds—by hashing the question into a key for a direct lookup. That's next lesson's star.

🧹

Dedup

Deduping training corpora, crawlers asking “have we fetched this page?”—hash the content into a Set and check. Otherwise pairwise compares on billions of rows run until heat death.

🎫

session lookup

Every time you open ChatGPT, the server takes your session id and finds your conversation among tens of millions of online users instantly—not by walking a roster.

What this lesson wants to share