[#86] Adds policy caching #111
Conversation
| if errs.is_empty() { | ||
| //if the cache has grown too large, clear it prior to adding new entries | ||
| if policy_cache.len() >= config.max_entries { | ||
| policy_cache.clear() |
There was a problem hiding this comment.
I'm a bit sad that this is the invalidation strat we're using. Even removing some arbitrary entry would be better, wouldn't it? Also, you didn't check to see if the if the insert would be actually replacing an entry (concurrent requests).
There was a problem hiding this comment.
I agree that it's pretty simple minded. All we're really trying to guarantee here is that the cache can't grow without bound for a long running process. I feel like anything smarter probably should include time or usage stats.
I did consider doing what you suggest and just throwing out a single, random entry, which seems reasonable, but then we need to introduce some machinery to decide which (random) entry to throw out and it just didn't seem worth it.
see #86
Adds simple policy caching for straightforward use cases where some number of policies are being evaluated repeatedly. Caching will greatly improve the performance of these usecases as it will save a roundtrip to the webservice per encryption.