Ristretto v2.4.2

[matthewmcneely]

Ristretto v2.4.2 is out — and please skip v2.4.1

v2.4.2 is released. It's a one-line fix, but an important one: it reverts a change from v2.4.1 that caused a sizable memory regression for some caches. If you're on v2.4.1, I'd upgrade to v2.4.2 straight away — and if you're on v2.4.0 or earlier, you can jump to v2.4.2 and skip v2.4.1 entirely.

What happened

v2.4.1 shipped #482, which pre-allocated the sampledLFU keyCosts map to NumCounters/10 at construction, on the assumption of the recommended 10:1 counter-to-item ratio. The intent was to avoid map resizing under load.

The catch is that keyCosts tracks admitted items, which are bounded by MaxCost and your cost distribution — not by the counter count. So for a cache with a large NumCounters and a working set that never gets near NumCounters/10, this committed a big block of empty map buckets at boot and held it flat, and clear() re-inflated to the same size instead of releasing. It reads as a flat RSS bump at startup rather than a leak, which is what made it easy to miss.

The size scales with NumCounters, so the impact depends on your config. On one Dgraph build with NumCounters ≈ 2^28, the pre-allocated map alone accounted for roughly half a GB of resident memory that lazy growth would never have touched. Smaller counter counts see proportionally less.

The fix

v2.4.2 reverts #482 — back to lazy map growth and a clear() that actually frees. No API changes, no config changes, nothing else in this release. Drop-in upgrade.

• Release: https://github.com/dgraph-io/ristretto/releases/tag/v2.4.2
• Details and analysis: Query films by Steven Spielberg ONLY? #493
• Revert PR: Filtering by count #494

What's next

Eager sizing is still a reasonable optimization when your working set really is close to NumCounters/10 — it was just wrong as a default keyed off the wrong quantity. I'd like to bring it back as an opt-in Config hint you can set when it fits your workload, rather than something that fires for everyone. Tracking that in #493, and happy to hear how folks would want to configure it.

Thanks, and apologies to anyone who got bitten by the v2.4.1 footprint.