Skip to content
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

Closed
whitfin opened this issue Aug 14, 2016 · 4 comments
Closed

Implement max_size and eviction policies #55

whitfin opened this issue Aug 14, 2016 · 4 comments
Assignees
Milestone

Comments

@whitfin
Copy link
Owner

whitfin commented Aug 14, 2016

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.

@whitfin whitfin added this to the v2.0.0 milestone Aug 14, 2016
@whitfin whitfin self-assigned this Aug 14, 2016
@whitfin
Copy link
Owner Author

whitfin commented Aug 14, 2016

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 touch their keys as needed.

@whitfin
Copy link
Owner Author

whitfin commented Sep 2, 2016

More thoughts on LRU:

  • We can provide a touch function which is basically refresh without updating the TTL (so it just updates the write time).
  • An LRU policy can simply invoke the LRW policy, but add in a hook which touches keys when they're read.
  • If you don't want all keys to be read, maybe we add a touch: false option to all read operations?
  • Alternatively, you can just use an LRW policy and touch keys when you wish.

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.

@whitfin
Copy link
Owner Author

whitfin commented Sep 3, 2016

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.

@whitfin whitfin closed this as completed Sep 20, 2016
@emerleite
Copy link

@zackehh thanks. I'll start using this next week ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants