State: Study to come to a proposal
Based on the information from T75208: Dependency Graph Evaluation Optimizations
During build time not all RNA_path_resolves can be determined.
Investigation
Current Code
depsgraph_query.c
- RNA_path_resolve is used in DEG_get_evaluated_rna_pointer what isn't being used. Should we remove this function?
depsgraph_builder_cache
Introduced by rBc8f3377d0353: Depsgraph: Add generic animated properties cache which is already adding a cache around RNA_path_resolve_property
deg_builder_relations.c
- there seems like an unneeded second lookup in build_driver_data; property_entry_key is the same as property_exit_key, but uses a different `source parameter. D7872: Depsgraph: Remove unneeded `RNA_path_resolve`
Cache hits
A cache only works if we can get a mechanism working with has cache hits. If a cache items is only used once (when created) it will add overhead. If a cache item can be shared across frames and or objects it is potentially better to cache. There is a potential that some rna_paths can be cached in the IDType. They could even by const evaluators as they can be determined at compile time and don't need to be cached at all. examples are 'Object.location/rotation/scale`.
The core of the dependency graph does all RNA_path_resolves during loading. When playing back the animation it doesn't call any RNA_path_resolve* (
does not output anything when playing back animation). This proofs that adding a dependency specific rna resolve cache wouldn't be a solution we would be needed.deg_* seems to be evaluated once when loading so caching this won't improve playback performance. A reason why we would want to cache this might be that the cache will be populated at this time so it reduces synchronization overhead during dependency graph evaluation.
This points us more in the direction to look into other areas where RNA_path_resolve is used inside a Node.
TODO
- create data that would help us check the best caching strategy
Research
- Is it possible to use a non-blocking lazy retrieval of the RNA_path_resolve during eval time.
- Add an evaluation expression cache on ID block similar to Python Expression.
- many rna paths are animated in groups (location.x, y z) by caching intermediates might also increase performance. as a single call will set the right pointer, and the second and third would only need to set the index. There the longer the paths are the more performance we get.
- FCurve: Could we add a FCurve_Runtime what holds a List of RNAProperties that can be evaluated when needed so it doesn't need to be constructed every time.
Proposal
This proposal is still heavily influenced by any progress in this ticket.
- CLEANUP: Should we remove DEG_get_evaluated_rna_pointer as it isn't used anymore?