[floatdrop]

What

GetMany(keys, values, found) on the three lock-free caches and on stats.Cache. It does what Get does for each key, in order.

• For up to 32 keys at a time, while at least 4 are left, it hashes them, loads the index slot each lookup starts at (cslab.Slab.Touch) and the node it points to (TouchNode), then runs the package's own lookup. The CPU fetches the memory of the whole batch in parallel.
• The last 1–3 keys of a call go through Get.
• It panics if values or found is shorter than keys, before it looks anything up.
• stats.Wrap uses the wrapped cache's GetMany if it has one, else loops Get, and counts a hit or a miss per key.
• Not on evict.Cache: lru and twoq have no GetMany.

Results (Apple M3 Max)

Change in time per key against a Get loop: ranges over the three caches of medians of three runs of BenchmarkGetMany, keys picked at random.

	1 CPU	8 CPUs
1M int entries, 32 keys per call	−48 to −62%	−47 to −53%
1M int entries, 8 keys per call	−36 to −49%	−27 to −34%
1M entries, 23-byte string keys, 32 per call	−66 to −68%	−56 to −58%
Zipf read-through with room for 1M, 32 per call	−49 to −55%	−48 to −51%
16K int entries, 32 keys per call	−2 to +3%	+1 to +9%
1M int entries, 1 key per call	+40 to +86%	+32 to +80%

• One key is slower through GetMany even though it only calls Get, and I did not find why: not the batch arrays, not the frame size, not inlining in the benchmark. The docs say to use Get for one key.
• The absolute times moved more between runs than these ratios, so the README gives ratios.
• Only darwin/arm64 was measured.

Why a batch method

A prototype was reviewed twice by separate agents, who reproduced the gain with interleaved one-process-per-variant runs and looked for ways to get it without a new method:

• Removing the pin CAS and the unpin store from Get made int lookups barely faster.
• Touching one key ahead of each Get gained nothing.
• A caller touching its whole batch and then calling Get got 85–90% of the gain but hashed every key twice, 36% slower on a 16K cache.

What pays is many independent loads issued back to back, which needs the keys in hand.

Checked

• Each package has tests that GetMany matches Peek key by key, for lengths around 32 and every remainder from 0 to 4, and with values being keys itself.
• Read counts after Get and after GetMany are compared per key, also with every reader slot taken so that lookups go through the lock. s3fifo also compares its queues after evictions, sieve the keys left, and tinylfu the hits its window hears of.
• Other tests: concurrent writers with keys that must always be found, help-out reclaiming, short slices writing and counting nothing before the panic, and no allocations.
• Mutations caught: not counting reads; the locked fallback not counting, dropping the value, or never taken; no help; no length check; the fallback using Peek or skipping keys; tinylfu not tallying hits on either path.
• Inline check: GetMany calls neither Touch nor TouchNode, used directly or through a generic type of another package; marking either //go:noinline makes it fail. stats.Cache.GetMany is covered the same way.
• golangci-lint 0 issues; go test -race ./... passes; GOOS=linux GOARCH=386 go vet ./... clean.

🤖 Generated with Claude Code