Add otter #5183
Add otter #5183
Conversation
|
Thank you for contributing to awesome-go. We will review your contribution as soon as possible. Make sure you add the links in the body of the pull request that are requested in the contribution guide:
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
PR Type: Enhancement
PR Summary: The pull request adds a new caching library named 'otter' to the list of Go caching solutions in the README.md file. The addition aims to introduce a high-performance, lockless cache that claims to be significantly faster than existing libraries such as Ristretto.
Decision: Comment
📝 Type: 'Enhancement' - not supported yet.
- Sourcery currently only approves 'Typo fix' PRs.
✅ Issue addressed: this change correctly addresses the issue or implements the desired feature.
No details provided.
✅ Small diff: the diff is small enough to approve with confidence.
No details provided.
General suggestions:
- It would be beneficial to provide empirical evidence or benchmarks to support the claim that 'otter' is 'Many times faster than Ristretto and friends.' This would enhance the credibility of the documentation and provide users with concrete data to consider when evaluating caching solutions.
- Ensure that the description of 'otter' adheres to the quality standards mentioned in the contribution guidelines, particularly in terms of grammar and clarity.
Thanks for using Sourcery. We offer it for free for open source projects and would be very grateful if you could help us grow. If you like it, would you consider sharing Sourcery on your favourite social media? ✨
| @@ -669,6 +669,7 @@ _Data stores with expiring records, in-memory distributed data stores, or in-mem | |||
| - [groupcache](https://github.com/golang/groupcache) - Groupcache is a caching and cache-filling library, intended as a replacement for memcached in many cases. | |||
| - [imcache](https://github.com/erni27/imcache) - A generic in-memory cache Go library. It supports expiration, sliding expiration, max entries limit, eviction callbacks and sharding. | |||
| - [nscache](https://github.com/no-src/nscache) - A Go caching framework that supports multiple data source drivers. | |||
| - [otter](https://github.com/maypok86/otter) - A high performance lockless cache for Go. Many times faster than Ristretto and friends. | |||
There was a problem hiding this comment.
suggestion (llm): The addition of 'otter' to the list of caching libraries is a good update, especially if it's performance is notable compared to existing solutions. However, the claim 'Many times faster than Ristretto and friends' should be substantiated with benchmarks or other empirical evidence to maintain the credibility of the documentation.
|
I just started writing about benchmarks... 😅 |
|
Okay, I'll still leave my notes on benchmarks for caches because it's extremely non-obvious and can be used as a source later on. 🙃 The benchmark that I use has a pre-populated cache with a zipf distribution for the access requests. That creates hot spots as some entries are used much more often than others, just like a real cache would experience. A common mistake is a uniform policy (distribution consisting of unique elements) which evenly spreads the contention, which would imply random replacement is the ideal policy. A skewed distribution means that locks suffer higher contention so it exacerbates that as a problems, while also benefiting contention-free implementations who can better utilize the cpu cache. Also the benchmark's overhead is thread-local work for an index increment, array lookup, loop, and operation counter. If we introduce a cost like data dependencies (such as by using a random number generator to select the next key), we'd see this fall sharply as we no longer allow the CPU/compiler to use the hardware's full potential. Why is the cache initially fully populated? Because a cache miss always takes much less time than a hit, since you don't need to update the eviction policy. Because of this, implementations with a small hit ratio get a huge advantage and as a result it is easy to misinterpret the results of such benchmarks. In the end, I think this is one of the best benchmarks to compare cache speeds because this micro-benchmark tries to isolate the costs to only measuring the cache in a concurrent workload. It would show bottlenecks such as due to hardware cache coherence, data dependencies, poor branch prediction, saturation of the logic units (there are multiple ALUs for every FP unit), (lack of) SIMD, waits on the store buffer, blocking and context switches, system calls, inefficient algorithms, etc. |
Please provide package links to:
Note: that new categories can be added only when there are 3 packages or more.
Make sure that you've checked the boxes below that apply before you submit PR.
Not every repository (project) will require every option, but most projects should. Check the Contribution Guidelines for details.
Thanks for your PR, you're awesome! 👍