Add a scheduled LRW policy for low memory use #306
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This closes #303 and #300.
This PR introduces a new implementation of the LRW policy which avoids the need for message passing in hooks. It operates on a (configurable) schedule to check the cache bounds. As such, it uses less memory but might have a larger delay on reclaiming space - pick your poison.
I moved
Cachex.Policy.LRWintoCachex.Policy.LRW.Eventedand delegated through to save the existing defaults, or people referencing that module already. The LRW logic stays insideCachex.Policy.LRW, because it's used in both places. It will also be used if we ever get around to #305.I think I want to change the default away from the evented version to the scheduled version, but I need to think more on this. Not only is the policy server more efficient, it will actually help throughput of your cache (because it's not pinging the LRW hook on every write). Given that the check is once per second, it seems like it should be hard to notice the change for most use cases.
I'm not sure I like
enforce_boundsas a public name, so need to think about that. Even something likeprune/2might be better as a public name. I also removed some junk in the policy space which was unused in favour of just using hooks going forward. I originally had bigger plans, which is why the spec stuff was in there - but at this point I think it's just bloat.