-
Notifications
You must be signed in to change notification settings - Fork 104
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement max_size and eviction policies #55
Comments
Currently I have an implementation of an LRW (least-recently written) hook which works and caps based on a given reclaiming boundary. This is implemented entirely without need for separate storage and is actually quite cheap, and seems to be pretty fast (as much as you can expect, anyway). Not entirely sure about how to create an LRU which doesn't need some sort of key tracking, which would naturally make it way more expensive (because there would be a write on every read). It may just be that we go with just LRW for 2.x and direct people to |
More thoughts on LRU:
This would mean that we only have one heavy lifting policy (LRW), but support both the LRW and LRU use cases. I think this is elegant, and should suffice for now - things like LFU would be extremely difficult to implement without introducing higher memory usage. |
LRW is merged in. LRU is going to take a little time because there are a few other issues to cleanup first before I take a shot at that (because I'd just have to rewrite it). @emerleite feel free to play around with Master to try out the limits. |
@zackehh thanks. I'll start using this next week ;) |
Based on #49.
Due to #51 being merged, we're now able to implement size limits on a cache without any race conditions. This will first make an appearance in v2.0.
Implementations should use hooks to avoid bloating the Cachex core. Policies to implement should be LRW (default) and LRU. More may come in future, but these are likely the two most popular. Policies based on frequency would be extremely difficult to implement without introducing either performance hits or memory costs.
The text was updated successfully, but these errors were encountered: