Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
maypok86
searching Neon…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
13 ms
·
1.
▲
by
maypok86
1y ago
I believe `ExpiryCalculator` is fairly self-explanatory. For example, `ExpiryWriting` returns an `ExpiryCalculator` that specifies the entry should be automatically evicted from the cache after the given duration from either its creation or
2.
▲
by
maypok86
1y ago
Putting aside performance metrics (latency, throughput, hit rate, memory usage), here's what I don't like: 1. I don't really see how the API is simpler. ccache has tons of methods like `GetsPerPromote`, `PercentToPrune`, `Buc
3.
▲
by
maypok86
1y ago
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 usin
4.
▲
by
maypok86
1y ago
I benchmarked ccache for throughput [1], memory consumption [2], and hit rate [3]. For hit rate simulations, I used golang-lru's LRU implementation, though I doubt a correct LRU implementation would show meaningful hit rate differences
5.
▲
by
maypok86
1y ago
Yeah, I basically agree with that.
6.
▲
by
maypok86
1y ago
What exactly do you mean by a "more specialized simple cache"? Just a map, mutex and LRU/LFU/ARC as eviction policies? 1. Even using sync.RWMutex and specialized policies won't really help you outperform a well-impl
7.
▲
by
maypok86
1y ago
No, I haven't looked into it, but the combination of "lock-free" and "S3-FIFO" raises some red flags for me :) I don't quite understand the specific rationale for replacing segmented LRU with S3-FIFO. If I reme
8.
▲
by
maypok86
1y ago
To be honest, I'm not sure I can recommend anything specific here. 1. How much data do you have and how many entries? If you have lots of data with very small records, you might need an off-heap based cache solution. The only ready-mad
9.
▲
The Evolution of Caching Libraries in Go
(maypok86.github.io)
128 points
by
maypok86
1y ago
|
34 comments
10.
▲
Otter v2: A high performance caching library for Go
(github.com)
3 points
by
maypok86
1y ago
|
1 comments
11.
▲
by
maypok86
1y ago
Today I'm excited to announce the release of Otter v2 - a high-performance caching library for Go. Otter v2 has been almost completely reworked since its first release to provide a richer API and new features while maintaining high per
12.
▲
by
maypok86
3y ago
1. Here I don't understand how you can do with one cas on a filled cache. You need to evict items on every insert, reinsert items into the main queue, etc., and if you add support for item weights, the number of xadd and cas operations
13.
▲
by
maypok86
3y ago
In fact, lock-free queues have several problems at once, which prompted me to give up on them almost immediately. 1. Yes, S3-FIFO can be implemented using lock-free queues, but the problem is that each write to a filled cache using this des
14.
▲
by
maypok86
3y ago
Hmm, I'd like to know more about the bugs and not updated results. It seems that all the bugs that were there long ago have been fixed (and even with some improvements). And the results show the latest version's performance. Espec
15.
▲
by
maypok86
3y ago
1. That's not the problem, yes, most web traces aim for zipf distribution, but you can't say it will work well in real life just based on this check (this was also mentioned in the S3-FIFO discussion here). Because there are many
16.
▲
by
maypok86
3y ago
In fact, to say that sieve is better is fundamentally wrong. 1. You only test the hit ratio on a synthetic zipf distribution and claim an advantage without saying a word about the problems (which there are). 2. Checking implementation speed
17.
▲
by
maypok86
3y ago
No, and it's not planned (otter tries to avoid additional pressure on gc if possible, but that's not always possible). And I'm extremely frustrated that I had to include bigcache and fastcache in these benchmarks, since many
18.
▲
by
maypok86
3y ago
1. Unfortunately, ristretto has been showing hit ratio around 0 on almost all traces for a very long time now and the authors don't respond to this in any way. Vitess for example has already changed it to another cache. Here are two is