Best Of

Author: Dana Evernden is a Principal Solution Architect at Anaplan, pioneering the Anaplan Delivery Assurance Program.

Polaris Building and Debugging Tactics 

Tired of sluggish models and performance bottlenecks in Polaris? Ever feel like you're just one tweak away from unlocking lightning-fast speed? You've found the link you've always needed. This is your definitive guide to transforming your models from frustratingly slow to incredibly responsive.  

A quick tip for build teams: The most successful, nontroubled projects treat performance tuning as a key part of the process. It’s a small investment that pays huge dividends in the end-user experience, resulting in customer trust that translates to continued implementation phases. Dive into these essential tactics and learn how to build, tune, and debug like a pro, ensuring your end-users get the seamless experience they deserve. 

How to Use This Guide 

• Establish the Foundation: Start with the Key Reminders, When to Use This Guide, and the Performance Checklist. These sections ensure you are applying Polaris best practices at the correct stages of the build lifecycle and within the appropriate model components. 
• Prioritize Impact: When evaluating model performance, follow the Steps for Prioritizing Optimization Opportunities. This section helps you focus on the most impactful metrics first, ensuring your tuning efforts yield the greatest performance gains. 
• Implement Solutions: Consult the Optimization and Debugging Tips for a deep dive into proven methods for refining formulas, reducing engine effort, and resolving common bottlenecks. 

Key Reminders for Building in Polaris 

When building in Polaris, keep these foundational principles in mind: 

• Use ALM from the start: Review this Iterative Development in Polaris community article to properly set up your environments. 
• Monitor metrics closely: Tread carefully and check Calculation Effort, Memory, and Populated Cell Count frequently when building in large, highly dimensionalized modules (e.g., output, reporting, or input modules). 
• Test piecemeal: Refer to the iterative development article to ensure you are testing complex modules in stages. 
• Stay sensitive to complexity: As model complexity increases, the risk of performance issues grows. Regularly check the performance metrics listed below. 

When to Use This Guide 

• Actions are running slowly. 
• Model open time is latent. 
• Cell data entry feels sluggish. 
• Routine performance health checks. 

Performance Review Checklist 

Periodically review these areas to ensure optimal speed: 

• Integrations: Monitor regularly scheduled data flows, both automated and manual. 
• Processes: Audit long-running processes. 
• UX Rendering: Check the speed of Boards, Pages, and input views. 
• Model Open Time: Review the calculation effort within the first 10 minutes of the model opening. 

If performance degrades, export the Line Items tab to pinpoint and optimize formulas. It is critical to test the model at scale by frequently pushing to a fully loaded Test model to test the most used features of the model.  

Refresher: Review the Anaplan Polaris – Calculation Effort article for more on identifying top-effort line items. 

............................................................................................................................………………………………..

Steps for Prioritizing Optimization Opportunities: 

1. High Calculation Effort + High Complexity + High GB: Focus here first. These line items offer the most room for improvement and impact cumulative performance (similar to Best Practices in Classic). Note that an inefficient calculation can have high calc effort even if it results in an unpopulated cell. Review the 'Calculation Effort’ section on Slide 17 onwards in this Community article presentation: Anaplan Polaris: A deeper dive into the Polaris Engine and model building techniques. It’s important to note that an inefficient calculation can have calc effort but still result in not populating a cell. 
2. High Calculation Effort + Computationally Intensive Functions: Address line items with high Calculation Effort that use functions like FINDITEM, ISFIRSTOCCURRENCE, RANK, RANKCUMULATE, and CUMULATE (performance can be dependent on data). 
3. Summary Methods: Review use of summary methods at very high cell counts. Can these be made end-of-chain to enable On-Demand Calculation (ODC)? Are all summary levels of the hierarchy needed? 
4. High Complexity + High Cell Count: Even if they have a small Populated Cell Count and Calculation Effort, they have the potential to cause performance issues if the addressable Cell Count and Complexity is high. 
5. ‘All Cells’ Complexity: Finally, focus on line items with Calculation Complexities that equal ‘All Cells’ in line items with high cell counts as they may pose a risk due to their inherent fully dense nature. 

A note on GB: GB is the size equivalent of the populated cells, and while it doesn't factor into performance directly it could validate the high complexity or calculation effort values. Very high GB would mean high populated cells which could be caused by high complexity. If complexity is low, high Populated Cells/Memory Use could be an indicator of a line item which might by optimized by making it end of chain so it can take advantage of ODC.  

............................................................................................................................………………………………..

Optimization and Debugging 

Optimization and debugging are a necessary step in any build timeline. Try these strategies below for ways to debug and optimize formulas as needed. 

Disclaimer - Anaplan's product team actively works to improve the performance of the Polaris engine, as well as provide information on new ways to debug latent modeling designs.  Any of the recommendations stated here are subject to change as these enhancements are released.  

• Use Guards Effectively: Review whether all dimensions are needed. If they are, favor 0, FALSE or BLANK with a ‘guard’ (an IF/THEN statement that introduces new information into the line item and introduces additional sparsity). Only do math where you need to, and review the 'Using Guards Effectively’ section on Slide 21 onwards in this Community article presentation: Anaplan Polaris: A deeper dive into the Polaris Engine and model building techniques 
• Source / Target Dimensionality: Review differing dimensionality between source and target of high complexity one-to-many or ‘All Cells’ line items. The more cells that populate, the more space/time that can take. 
• Populated Cells Necessity: Avoid formulas that result in ‘All Cells’ when applied to a substantial number of cells in a line item 
• Formula Reversion: As you try improving efforts, you may need to revert back if the calculation effort (at model open time) or complexity doesn’t show improvement  
• The "Master Switch": For complex formulas and long running processes, create a SYS Calculate? Boolean master switch to be used in high effort formulas and to pause real time data flows. An example is disabling calculations during a multi step data load process, then enabling calculations as the last step of the process 
• Memory Efficiency: Avoid unnecessary or inefficient memory: 
• Summary cell counts & memory are big multiples of leaf level 
• Aggregation by Sum is fast, aggregation by Formula, Ratio, Any, All, First Non-Blank and Last Non-Blank require more calculation effort  
• Considerations when using LOOKUP:  
• [LOOKUP] against very large data sources requires more calculation effort 
• Multiple Lookups tend to use up additional calculation effort, attempt to use SUMs instead if possible 
• Nested IFs: For complex nested IF statements, try an iterative approach by looking at the number of populated cells and complexity for multiple approaches to debug and reduce engine effort. You could try splitting out nested IF statement formulas if they are non-performant. However, when you break up a formula, you might inadvertently force the engine to calculate more cells than it would otherwise, which could outweigh any benefit of increasing parallelization. Review the Optimizing Calculation Performance Using Inline Conditions community article for further details 
• Optimize “near” a slow line item: If a line item is slow performing and you have optimized it as much as possible, review down and upstream formulas for higher calc effort/complexity formulas and attempt to optimize those. 
• Minimize use of User-based filters: User-based filters on rows do not perform well at high dimensionality and can lead to very dense and large filter line items. It's encouraged to model at natural dimensionality and/or use a native UX filter for optimal performance. 
• Cyclic Errors: While debugging an error described as ‘there are non-winding cyclic calculations involving the line items’, split the formula out to see which piece is causing the circular reference. Next, see if using staging line items (adding the lookup in a line item separate from the previous statement) will work. 
• Time Period Review: Specific Time Ranges and calculation Booleans (i.e., A rolling 24-month Boolean) can help with confirming calculations that populate cells only occur at the relevant time periods 
• Seed DEV Lists with one member: All dimensions in DEV should have at least one list item so Polaris will reject invalid formulas (i.e., Non-winding cyclic error). 
• Investigate line items that have populated cell counts a lot higher than the other line items in the same module. These line item may be utilizing memory unnecessarily and are likely not able to take advantage of ODC. 
• Filters, DCA, and CF can take up excess memory. Less memory can be used when biasing the formula toward majority False instead of True. Centralize and reuse filters whenever possible 
• When reviewing export actions, leveraging the Tabular Multiple Column Export becomes even more important with Polaris, where datasets can be exponentially larger. Review the 'Tabular Multiple Column Export' section on Slide 35 onwards in this Community article presentation: Anaplan Polaris: A deeper dive into the Polaris Engine and model building techniques 
• Separate models by business process: Confirm that your models reflect your business process flow and natural break points.  
  • Pros - shortens calculation chains, reduces unnecessary recalculations, and separates security requirements by business function 
  • Cons – Adds complexity to data integrations, breaks 'real time' views 
• Workspace allocation: Ensure that no more than one Polaris model is in a workspace. 
• Optimize export views: With very large grids, do not give users the ability to both pivot and export. The default pivot with all levels of all dimensions is going to be very large … and will lock up the model when exported. The new Combined Grids feature is the way to go for efficient and compact leaf-level exports. Review this article on best practices for view optimization when importing and exporting. 
• Delta loads: Do not rely on Full clear-and-reload for intraday updates to reporting models. Instead, load Deltas only by staging data from upstream input models to an intermediate model in a flat structure with a Current / Previous dimension. 
  • Users in the reporting model will not encounter long “model is busy” delay due to time to pull from upstream models. These slow pulls will happen in the background with no impact on the Reporting model. 
  • For incremental load view, filter the data for Current <> Previous. The flat data with a single filter will have negligible delay. Routine updates will load to Reporting in seconds. 
  • For the customer’s peace of mind, provide a Full (unfiltered) load option to allow for easy recovery if the incremental load fails. 
• DCA optimization: To debug DCA formulas that may be causing performance issues: 
  • Determine if Selective Access can be used in place of DCA. 
  • Question whether the DCA driver really needs every dimension in the Applies To.  
  • Use early exit where possible.  
  • Avoid text operations like comparing strings or FINDITEM
  • Avoid ISFIRSTOCCURRENCE on large lists. 
• Conditional Formatting Optimization: For Conditional Formatting, beware of tiny-but-not-quite-zero values, they take memory but don't provide any benefit for conditional formatting.  Use ROUND to empty those tiny values. 
• List loads: Adding list members to a list can potentially create trillions of cells, which requires calculation upon loading, which could result in longer load times. Consider decoupling the modules needed downstream with the modules immediately needing the list member addition, run the action less frequently, or create dummy members within the list so calculation upon list item creation is not needed. Review the 'Inserting List Members’ section on Slide 31 onwards in this Community article presentation: Anaplan Polaris: A deeper dive into the Polaris Engine and model building techniques 

 ............................................................................................................................………………………………..

You now hold the keys to peak Polaris performance. By embracing these proactive strategies, you can move beyond simply building models and become an architect of truly exceptional, high-speed planning solutions. 

Remember, the most successful teams make this a routine: They periodically check the end-user experience, test key functionality for latency, and carve out sufficient time to prioritize optimization. Bookmark this guide, share it with your team, and make performance a core part of your development lifecycle. The power to build better, faster models is in your hands.