The Evolution of Caching Libraries in Go and Ristretto's zero hit rate mystery

Re:The Evolution of Caching Libraries in Go and Ristretto's ... by maypok86 on Thursday July 03, 2025 @01:18AM (#44451868)

No, what do you want to verify? Any network calls make Redis significantly slower than an on-heap cache. I'd even argue these are tools for different purposes and don't compare well directly.

A common pattern, for example, is using on-heap caches together with off-heap caches/dedicated cache servers (like Redis) in L1/L2/Lx model. Here, the on-heap cache serves as the service's first line of defense, protecting slower, larger caches/databases from excessive load.

[ Parent | on HN ]

Re:The Evolution of Caching Libraries in Go and Ristretto's ... by nchmy on Thursday July 03, 2025 @04:14AM (#44452791)

Yes, I assume that otter etc are vastly faster, but I suspect there's people who are not aware of that. So, the idea was to show how much faster to further promote adoption of such tools.

And, to clarify, I was only thinking about localhost/Unix sockets to mostly eliminate network latency. Anything external to the server would obviously be incomparably slower.

I also suppose that it would be interesting/useful to compare the speed of these in-memory caches to Golang caches/kv stores that have disk persistence. Obviously the type of "disk" would matter significantly, with nvme being closer in perf (and probably sufficient for most applications)

Anyway, it was just a thought.

[ Parent | on HN ]