We have discovered that Line Item Subsets cause unexpected behaviour in Polaris: their mere existence adds significantly to model size and calculation demand. This overhead is undocumented (it appears in neither Anapedia nor the Planual) and is not visible to the model builder during building. The only way to detect it is by analysing "size leakage", meaning the gap between the sum of all line item sizes and the total model size.
A concrete example illustrates the scale of the impact:
- A module with 9 line items is 1.13 GB on its own. Total model size is 1.76 GB.
- Adding a Line Item Subset to this module, with every line item selected, increases total model size to 2.89 GB.
- Adding a COLLECT() module on top increases it further to 3.6 GB, roughly tripling the footprint of this single module.
- Note that the On-Demand Calculation engine also affects calculation demand to some degree, so model size impact can vary from case to case.
Feature Request: Improve transparency and documentation of Line Item Subset overhead in Polaris
- Document the behaviour. Add an explicit entry to Anapedia and the Planual explaining that Line Item Subsets carry a structural size/calculation cost in Polaris so that Solution Architects can consider the cost/benefit when designing a solution.
- Surface the cost to model builders. Extend the model size/usage reporting to break down calculation demand by structural element, including Line Item Subsets. This would let builders catch size leakage proactively instead of reverse-engineering it after the fact.
- Investigate reducing the overhead. Assess whether the underlying calculation cost of Line Item Subsets can be optimised in Polaris, since a near-tripling of a module's footprint from structural elements alone seems disproportionate to the functionality gained.
