-
Notifications
You must be signed in to change notification settings - Fork 8
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
Add ProtocolDAGResult
caching to user-facing client
#58
Comments
@dotsdl it looks like we're already doing (a)LRU caching for PDRs (although we have up to 10000 in maxsize, which I think is pretty aggressive). That said, we could just add a disk check inside the relevant methods. I think that will achieve what you proposed. Does that sound good to you? |
@ianmkenney our use of the (a)LRU cache there is rather crude, since usages of Do you think it's feasible to create a single in-memory cache using e.g. a |
Can we also expose the cache settings (e.g. location, max records, etc.) as kwargs to the |
ProtocolDAGResult
s are pulled by users to evaluate free energy differences forTransformation
s they are interested in. These can be rather large, and many can be pulled for a givenTransformation
in a single client method call. This can cause slow behavior for users, killing productivity.Because
ProtocolDAGResult
s never change once created, there is no risk of a stale cache. This make cache invalidation a non-issue for these objects.Caching should be two-tier:
When a
ProtocolDAGResult
ScopedKey
is slated for retrieval:ProtocolDAGResult
is returned; if not,ProtocolDAGResult
is returned; if not,The text was updated successfully, but these errors were encountered: