Bounded cache #33
Bounded cache #33
Conversation
There is a new typeclass, CacheableSource, with a single function cacheSize. This function specifies the size (in terms of the number of requests) that are cached for each request. 'Nothing' indicates an unbounded cache, while 'Just n' says that at most n requests are cached. Bounded caches allow handling of large data volumes, at the expense of sacrificing the consistency guarantee that the cache usually grants in Haxl. The bounded cache is based on the psqueues package.
Also, clearly state in the docs that choosing a bounded cache sacrifices replayability.
DataCache.lookup now has result Maybe (res a, DataCache res) instead of Maybe (res a).
|
Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla - and if you have received this in error or have any questions, please drop us a line at cla@fb.com. Thanks! |
| @@ -1,5 +1,5 @@ | |||
| loadCache :: GenHaxl u () | |||
| loadCache = do | |||
| cacheRequest (CountAardvarks "yyy") (except (LogicError (NotFound "yyy"))) | |||
| cacheRequest (CountAardvarks "xxx") (Right (3)) | |||
There was a problem hiding this comment.
The order in which the cacheRequests are listed is changed by 3f64d48,
so I changed this file to match with what I get. As far as I can tell, the order is not relevant, is it?
- Use Hashmap.insertWith again in the cache. That's how it was originally done before introducing bounded caches. It should be slightly faster. Also, for some reason, using a HashMap.lookup required additional constraints on the request type that were problematic on older ghc versions. - Make FiniteCache.insert strict in key and value - Also, added an export list to the module Haxl.Core.FiniteCache.
|
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks! |
|
Taking a glance over this, it is slightly intrusive and touches some performance-critical bits (e.g. |
|
Yes, unfortunately it's rather intrusive. I'm also not sure whether the use case this opens up, transferring large amounts of data, is something that other Haxl users will want to do. |
|
Hi @jkomyno, |
|
@jkomyno in principle I have no objection to including a bounded cache of some kind, but it needs to have zero (or close to zero) overhead. |
This is my proposal for #32. It enables users of Haxl to use caches of bounded size, but keeps "cache everything" as the default behaviour.
Please let me know if you have any remarks or want me to change anything.