In lesson 1 gen got a -dup-rate flag: a share of the titles are repeated. What it will do to a hash table looks obvious — identical titles, more collisions, longer chains.

Guess before you read on

10,000 items, -dup-rate 0.9. More comparisons per lookup than at -dup-rate 0, or fewer?

The measurement

$ for r in 0 0.3 0.5 0.9; do algo gen -n 10000 -seed 7 -dup-rate $r -o dup.jsonl; algo index -in dup.jsonl; done

  dup-rate   stored   buckets   resizes    load   longest   cmps/lookup
       0      10000     16384        10   0.610         5         1.310
     0.3       6994      8192         9   0.854         7         1.474
     0.5       4999      8192         9   0.610         5         1.308
     0.9        972      1024         6   0.949         5         1.722

The chains did not lengthen. The longest sits between 5 and 7 — exactly as it does with no duplicates at all. The comparison count moves between 1.31 and 1.72, and it moves with the load factor, not with the duplicate share (the 0.9 run has a load of 0.949, the highest in the table, which is why its 1.722 is the highest too).

What changed is stored: 10,000 → 972.

Why

Step 2 stated the distinction; here it is measured:

• a collision is different keys in the same bucket. It lengthens a chain;
• an equal key is the same title a second time. Put replaces it, and one entry remains.

-dup-rate 0.9 produces equal keys. The index merges them, so 972 distinct titles remain instead of 10,000. The table does not fill up — it shrinks: 1,024 buckets instead of 16,384, six resizes instead of ten.

And one more place -dup-rate now means something

In lesson 8 duplicates were interesting because of stability: equal keys whose relative order a sort can destroy. Here they are the opposite kind of thing — an equal key in a hash table cannot occupy two places, because "one key, one place" is the entire idea of the structure.

The same flag, two completely different questions. Which is why it was built in lesson 1 rather than in lesson 9.