Hi Everyone,
Greetings!
I'm looking for recommendations on further optimizing a performance-intensive line item in Polaris.
Background
I have a module (Expense) containing a Boolean line item (X) with the following dimensions:
- Time
- L5 Flat Product
- L3 Flat Channel
- L5 Flat Expense
- Expense Actions
Note: All flat lists are intentionally designed this way for performance and business requirements. Converting them to hierarchies is not an option.
Original Design
Initially, the Boolean line item used multiple LOOKUPs directly in the formula:
Issues Observed
- Extremely high model open/load times.
- This single line item accounted for approximately 95-96% of the model calculation effort/size.
- Adding new members caused significant increases in calculation overhead.
Optimization Performed
To reduce lookup calculations, I broke the logic into separate modules:
Module 1
Module 2
Module 3
Each module evaluates its respective selection independently.
The final Boolean line item now simply combines these results:
Current Result
This significantly improved performance:
- Calculation effort reduced from ~96% to ~47.8%.
- Lookup-heavy design has been eliminated.
However, the final Boolean line item is still the largest contributor to model effort.
Current Problem
Although the calculation is much lighter now:
- The final line item still consumes approximately 47.8% of the total model calculation effort.
- Model size continues to increase rapidly whenever a new member is added to the Expense Actions list.
- The final line item is dimensioned by all the flat dimensions mentioned above, resulting in a very large intersection count.
Questions
- Are there any Polaris-specific optimization techniques for large Boolean calculations across multiple high-cardinality flat dimensions?
- Does the use of multiple Boolean line items combined with
AND still create significant storage overhead at large scale? - Would creating intermediate aggregation modules or reducing dimensionality in helper modules provide further gains?
- Has anyone successfully optimized similar use cases where a single Boolean line item spans multiple large flat lists?
- Are there design patterns in Polaris that help minimize recalculation and space usage when a dimension like Expense Actions grows frequently?
Additional Context
- Polaris model.
- Final line item is Boolean formatted.
- Flat lists are required by design and cannot be replaced by hierarchies.
- LOOKUPs have already been removed from the final calculation path.
- Main concern now is calculation effort and model growth as Expense Actions expands.
Any suggestions, design alternatives, or Polaris best practices would be greatly appreciated.
Thank you
