Most "Anaplan is slow" tickets are not really about size. We have tuned models with two billion cells that opened in seconds, and 200-million-cell models that took four minutes to open and 40 seconds to recalculate a single input. The difference is almost never the row count — it is how the formulas are written and where they sit.
The DISCO blueprint covers structure: which modules exist and what belongs in them. This tutorial is the layer below that. It assumes you already have a model in production, you cannot rebuild it this quarter, and you need it faster by Friday. Everything here is a change you can make module by module, measuring as you go.
Step 0: Measure before you touch anything
Tuning without a baseline is guesswork, and guesswork in Anaplan usually means someone spends two days on a formula that accounts for 1% of the calculation chain.
Collect these numbers first:
- Model size and cell count, from the model's settings, plus the per-module cell counts. Sort modules by cell count descending. Your problem is almost always in the top five.
- Open time, measured cold: fully close the model, wait for it to be unloaded, then open it and time it with a stopwatch. Do it three times and take the median.
- Edit-to-recalculate time for the two or three inputs planners complain about. Change one cell, time until the model releases the UI.
- Action durations for your main imports and processes, from the process run history.
Write these into a plain table and keep it open. Every change below gets a re-measurement in the same table.
| Metric | Baseline | After change | Delta |
|---|---|---|---|
| Cold open | 3m 50s | ||
| Cell edit: Volume Input | 38s | ||
| Process: Load Actuals | 11m | ||
| Largest module cells | 640M |
If you have access to a workspace administrator, also request the model's calculation profile from your Anaplan support contact or partner. It tells you which line items dominate the calculation chain, which turns this whole exercise from inference into arithmetic.
Step 1: Find the sparsity, not the size
Anaplan's Hyperblock calculates dense blocks fast. What it does not like is enormous cell counts where almost every cell is blank or zero. A module dimensioned by Product (12,000) x Customer (40,000) x Month (60) is 28.8 billion cells even though only 2% of product-customer pairs ever trade.
Compute the sparsity ratio for your top modules:
sparsity = populated combinations / total combinations
Product x Customer x Month
= 12,000 x 40,000 x 60 = 28,800,000,000 cells
Actual trading pairs = 96,000
Populated = 96,000 x 60 = 5,760,000
sparsity = 0.02%
Anything under a few percent is a candidate for a combination list: a flat list whose members are the valid pairs that actually exist (P1042_C7781), with properties or a system module holding the Product and Customer mappings. You then dimension the detail module by combination x Month instead of Product x Customer x Month, and aggregate up via SUM through the mapping.
This is the single highest-leverage change available in a sparse model, and it routinely cuts a module from billions of cells to single-digit millions. It is also the most invasive, so do it on the biggest offender only, and only after Steps 2 through 6 — those are cheaper and often enough.
Step 2: Replace repeated LOOKUP with one mapped intermediate
This is the most common performance bug we find. A module has eight line items, and each of them ends in the same LOOKUP:
// SLOW: the same lookup evaluated eight times
Revenue = Volume * Price Master.Price[LOOKUP: Product Mapping.Product]
Discount = Volume * Price Master.Discount[LOOKUP: Product Mapping.Product]
Freight = Volume * Price Master.Freight[LOOKUP: Product Mapping.Product]
...
Each LOOKUP is a cell-by-cell dereference across the whole module. Doing it eight times does the same expensive work eight times.
The fix is to pull the looked-up values into the target module's dimensionality once, in a small staging module, then reference them as plain line items:
// Staging module: dimensioned by SKU (the target granularity)
Price = Price Master.Price[LOOKUP: Product Mapping.Product]
Discount = Price Master.Discount[LOOKUP: Product Mapping.Product]
Freight = Price Master.Freight[LOOKUP: Product Mapping.Product]
// Calculation module: no LOOKUP at all
Revenue = Volume * Staging.Price
Discount = Volume * Staging.Discount
Freight = Volume * Staging.Freight
The rule to internalise: a LOOKUP or SUM should appear once per source line item per granularity, never once per consuming formula. If you see the same [LOOKUP: X] twice in a module, you have found free performance.
Step 3: Break long SUM/LOOKUP chains at the coarsest possible level
Aggregation cost scales with the number of source cells, not target cells. So aggregate as early — and from as small a source — as you can.
A chain like this recalculates the whole detail plane every time anything upstream changes:
// SLOW: aggregating detail straight to the top
Group Revenue = Detail Module.Revenue[SUM: Detail Module.Region, SUM: Region.Group]
Better is a stepped aggregation, where each step is a separate line item over progressively smaller data:
Region Revenue = Detail Module.Revenue[SUM: SKU Details.Region]
Group Revenue = Region Revenue[SUM: Region Details.Group]
Two further habits matter here:
- Sum before you multiply or divide when the maths permits it.
SUM(Volume) * Priceis far cheaper thanSUM(Volume * Price)when price is constant across the aggregation. - Do time and version calculations at the highest usable level. Computing a 12-month rolling average on a 5-million-cell detail module and then aggregating is dramatically worse than aggregating first and computing the average on 40,000 cells.
Step 4: Get text, and most IF logic, out of hot modules
Text is the heaviest data type in Anaplan, and text formulas evaluated across large modules are a common hidden cost. In any module in your top-five cell count list:
- Move formatted labels, concatenations and codes into a system module dimensioned only by the list (no time, no versions). Compute
Product Name & " (" & Code & ")"once per product, not once per product per month. - Replace text comparisons with boolean or list comparisons.
IF Status = "Approved"across 50 million cells should become a boolean line itemIs Approved?computed once in the system module. - Replace long nested IF ladders driven by a text or list attribute with a mapped lookup on a small driver module. A five-level nested IF is five evaluations per cell; a lookup against a 30-row rates module is one.
// SLOW: text comparison and nested IF over the full plane
Rate = IF Product Type = "Premium" THEN 0.12
ELSE IF Product Type = "Standard" THEN 0.08
ELSE IF Product Type = "Value" THEN 0.05 ELSE 0
// FAST: one small rates module, one reference
Rate = Product Type Rates.Rate[LOOKUP: SYS Product.Product Type]
As a bonus, the fast version is maintainable by the business without a builder touching a formula.
Step 5: Eliminate subsidiary views
A subsidiary view is created when a line item has different dimensionality from its module — for example, one line item in a Product x Month module that is Product-only. Anaplan then stores and calculates that line item as its own separate block. A handful is tolerable; dozens make a model slow to open and hard to reason about.
Find them by opening the module's blueprint and looking at the Applies To column: any line item with a value there is a subsidiary view. Fix them by moving those line items into a properly dimensioned module of their own — usually a system module for list-only attributes, and a summary module for time-only or version-only values.
This change frequently produces the largest improvement in open time specifically, which is the metric planners feel most acutely.
Step 6: Turn off summaries you do not use
By default, every numeric line item calculates and stores aggregations at every level of every hierarchy it touches. On a large module that is a lot of arithmetic performed on data nobody looks at.
In the blueprint, set the Summary setting to None for:
- Input line items that are only ever read at the leaf level.
- Intermediate calculation steps that exist only to feed the next line item.
- Rates, prices, percentages and flags, where a summed total is meaningless anyway. (If a total is wanted, use
FormulaorRatio, notSum.)
On a wide module with 60 line items, switching the intermediates to None can cut both cell count and recalculation time by a third or more, with zero change to reported numbers. Verify the last part: run your standard reconciliation reports before and after.
Step 7: Tune the loads, not just the formulas
If your complaint is "the nightly load takes two hours," formulas may not be the problem at all.
- Import into flat staging modules with no formulas, then calculate downstream. Importing directly into a module full of dependent formulas forces recalculation during the load.
- Import by code, never by name. Name matching is slower and fragile.
- Delete before insert on transactional lists using a dedicated "Delete from list using selection" action, rather than letting the list grow and relying on filters.
- Split one giant process into parallel-safe chunks where the dependency graph allows it, and sequence the rest.
- Check for
Include all line itemsin views used by imports — exporting or importing through a view that carries unnecessary line items multiplies the work.
A tuning session that actually finishes
A realistic half-day sequence on a live model:
- Baseline all four metrics (30 minutes).
- Blueprint sweep of the top five modules: list every subsidiary view, every duplicated LOOKUP, every text formula, every
Sumsummary on an intermediate (60 minutes). - Fix summaries and duplicated LOOKUPs first — lowest risk, immediate payback (90 minutes).
- Re-measure. Record the delta.
- Move text and attribute logic into system modules (60 minutes).
- Re-measure. Record the delta.
- Write up the sparsity case for the largest module as a separate, scheduled piece of work with a proper test cycle.
Do all of this in DEV, promote through your normal ALM release process, and reconcile totals at every step. Performance work that changes a number is not performance work; it is a defect.
What to do when tuning is not enough
Sometimes the answer is genuinely architectural: the model is one monolith doing data hub, calculation and reporting duties at once, or the data is so sparse that Hyperblock is the wrong engine and Polaris deserves a look. Tuning buys you the runway to make that decision calmly instead of during quarter close.
If you are staring at a model that opens in minutes and nobody remembers why, our performance optimization for Anaplan models team does exactly this diagnostic — measured baseline, prioritised fix list, and a before-and-after you can show your sponsor. Get in touch with your model size and open time and we will tell you what we would look at first.