caching: size GetMany copy arena by unique probes

[snissn]

Summary

• Size the published-root GetMany copy arena from the number of unique probes instead of total requested keys.
• Keeps the allocation-count win from the arena-copy stack while avoiding duplicate-heavy over-allocation.
• Leaves distinct-key behavior unchanged except for the same existing arena path.

Validation

• go test ./TreeDB/caching -count=1
• go test ./TreeDB/caching -run ^ -bench ^BenchmarkGetMany_PublishedRootPointShards -benchmem -benchtime=300ms -count=5 -p=1

Benchmark evidence vs current origin/main (d55deb8ae5):

duplicate64:       1.965 us/op -> 1.788 us/op, allocs 73 -> 9
duplicate256_hit: 6.806 us/op -> 5.895 us/op, allocs 265 -> 10, bytes roughly flat
duplicate256_miss:6.915 us/op -> 6.464 us/op, allocs 269 -> 20
distinct8:        roughly flat/slightly slower; this is a duplicate-heavy GetMany win

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: adac971eb4

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Size the arena by copied result count

For duplicate-heavy GetMany calls with non-trivial values, len(unique) can be 1 while copyToRefs still appends the value once for every duplicate ref in groupRefs. Starting the arena at unique * 128 therefore forces repeated reallocations, and the returned slices from earlier appends keep those old backing arrays alive, so a call like hundreds of duplicate probes for a 128B+ value can retain extra copied buffers and lose the allocation benefit this path is meant to provide. The allocation hint needs to reflect the number of output copies, not only the number of lookup probes.

Useful? React with 👍 / 👎.

[Copilot]

Pull request overview

This PR refines the GetMany fast-path for published-root point shards by sizing the value-copy arena based on the number of unique probes rather than the total number of requested keys, reducing unnecessary preallocation when the request contains many duplicate keys.

Changes:

• Allocate the published-root GetMany copy arena using len(unique) instead of len(keys) to avoid duplicate-driven overallocation.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.