 |
Workspace 6.21.5
|
|
Workspace 6.21.5
|
This operation allows you to cache values provided at the input in such a way that the value input is only updated if the provided key has not yet been encountered and a value for it stored. In effect, the value input only needs to be updated once for a given key.
The purpose of this operation is to avoid having to recompute a value that has been computed previously. The terms "compute" and "value" as used here are fairly loose definitions. Any clonable data type the workspace knows about can be used as a value, and most data types are clonable. The way the "value" is supplied to the CacheData operation is irrelevant, since the operation only sees the final result via the value passed to it. Thus, "compute" here means any workspace execution required to supply the value.
Only clonable data types can be cached. This is because the cache stores a copy of the data and it uses cloning to make the copy. This ensures that dynamic data types are handled properly (eg a derived object being stored in a base object).
A reset input is provided so that the cache can be cleared. This is an all-or-nothing facility, ie it is not possible to clear only specific items from the cache. It is possible to limit the number of items stored in the cache, but not the amount of memory the cache uses because there is no way to reliably tell how much memory a given data object actually uses.
Note that changing the data type will clear the cache.
The CacheData operation is polymorphic, meaning the user can change the data type being cached. Any time the data type is changed, the cache is cleared. The user can force the cache to be cleared at any time by causing the Clear cache input to become not up to date, which is generally accomplished by pressing a push button attached to that input. It is not possible to clear only specific items from the cache.
The caching mechanism has no concept of the size of the cached items. All items are treated equally except for their time since last being provided to the output. The internal cache is maintained as an ordered list and each time an item is supplied to the operation's output, that item is moved to the bottom of the list. Whenever an item needs to be discarded from the cache because the item limit has been reached, the item at the top of the list is chosen. Because the cache is not aware of the size of the items it holds, there is nothing stopping memory being exhausted other than setting a sensible item limit for whatever the data the cache is holding represents.
Users should be aware of how a workspace is updated and how that interacts with caching data. When using atomic nested workspaces, before the nested workspace is executed, all its inputs are brought up to date. This needs to be kept in mind, as the following example demonstrates:
In this example, the value input is always brought up to date when the nested workspace is atomic. Thus, the CacheData operation is useless in the case of an atomic nested workspace because it doesn't prevent the value being recomputed. Instead, the CacheData operation needs to be put in the same workspace that does the computation (probably the parent workspace in the above example) to allow it to avoid triggering an update of the value's execution path.