Firstly, strictly speaking, the graph itself isn’t directly executed, but used to build a queue of jobs which are then dispatched to the calc node.
With regard to the scope of graph building, no, the graph is made for the initial cycle and then re-analysed for each subsequent cycle.
What happens in the current build is that if anything has changed between cycles that means the previous graph is not still valid, it rebuilds the dependency graph in it’s entirety.
However, the work to improve this situation, and slightly alter some of the function interface is currently waiting on a branch for integration once we’ve pushed out the 1.2 release. This will:
- Better track portfolio changes, and they will themselves automatically trigger dependency graph rebuilds.
- Remove the need for ID combining inside the PositionSource by removing the requirement that Positions need to know which portfolio nodes they belong to. We found alternative solutions to the scenarios we originally thought this would be required for (e.g. computing component VaR).
- Make the target type concept much more flexible by replacing the current PRIMITIVE/SECURITY/POSITION/TRADE/PORTFOLIO_NODE target types with a class-based system. This will improve flexibility, make the engine more efficient at building the dependency graph (because it can more quickly find the functions necessary) and allow the use of custom types of target.
- Perform incremental rebuilds of the dependency graph only rebuilding what's required between cycles. This should lead to a pretty substantial performance increase when running scenarios and make everything faster and smoother.
Work is also ongoing on the ability to spawn sub-view processes from an engine function. This will allow, for example, a single view cycle to compute e.g. full reprice VaR or initiate a scenario itself.