[greenclaw]

I checked the "Choosing a Cache" page against the code and 6.2.9 and fixed what did not match:

• Complexity header: the costs are expected (hash table) and amortized, not worst-case; e was used without a definition.
• TTL insert: O(e+1)~ instead of O(e)~ — an insert with nothing expired is O(1) (about 160–200 ns with 1k and with 100k live entries).
• LFU: get only bumps the counter and the heap is repaired on the next eviction (lazyheap.rs repair_root / apply_pending), so one popitem after k reads is O(k log n). Added a note, plus one on LFU/VTTL iteration re-sorting.
• Cache overflow message: the real text is "The cache has no algorithm to evict items".
• LFU ties: broken by insertion order, not recency (insert a, b; read b, then a; the next insert evicts a).
• Lazy expiry note: get/[] treat expired entries as misses but do not remove them, and len()/bool() count them until an insert, iteration, current_size() or expire(). The tips link anchor was #ttlcachevttlcache-...; the page id is #ttlcache-vttlcache-background-thread.
• VTTL example: len(cache) printed 4, not 0, after the sleep; the example now calls expire() first.
• Iteration: in LRUCache, get and [] invalidate open iterators; in LFUCache, a new iteration after a read does.

Every changed snippet was run against 6.2.9, and mkdocs build renders the page with the fixed link.

One thing I left as is because I'm not sure which side is intended: the page says TTLCache evicts "FIFO among live entries". In the code, overwriting a key gives it a new expiry but keeps its place in the queue, so a refreshed live key can be evicted while an older expired one stays, and popitem() on TTLCache/VTTLCache can return an expired entry. Is that the intended behaviour (then I'll update the wording here), or should eviction/popitem drop expired entries first?

[awolverp]

Thanks for the corrections.

popitem() on TTLCache/VTTLCache can return an expired entry.

You made a good point! I am fixing this issue.