-
-
Notifications
You must be signed in to change notification settings - Fork 60
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
Allow a caching object that can cache specific entries #815
Comments
Nodes could work nicely for this 🙄 |
Ah yeah, good idea! 🚀 What is the overhead here? And can you tell it to not do it all-over? Only on return values? Seems like an ideal place to start...! :) |
By not all-over you mean that the nodes should not store the inputs? |
I seem to recall your nodes would traverse ast, and take everything, what we only want is the inputs, and the output, all in between shouldn't be nodified. |
Nooo, there are two things: If you convert a function into a node, then the node is simply a wrapper over the function to make the function (optionally) lazy and (optionally) cache the return value based on the inputs, as well as being able to connect it with other nodes so that an update (optionally) flows down the connected nodes. If you convert it into a workflow, then the function is split into nodes (not recursively, just one level up the stack). So what we would want here is simply to convert the functions to nodes, so that we can connect the output of |
nice, I'll play with this soon! Sounds like a perfect fit here! |
Describe the feature
Example.
Once a
State
has been created with aparent
, we mightas well turn it into a cached object, which when calling specific
methods it returns the objects needed fast. Typically users
won't be storing all k-point's eigenstates, and thus one could
get free performance by allowing users to do this:
However, there are some things that shouldn't be cached. For instance
it does not make sense to cache the
geometry
orsub
commands.So how do we selectively decide which methods to cache, do we need to mark them as "cacheable"?
The text was updated successfully, but these errors were encountered: