Improving TM1 Performance: Why more RAM is rarely the right answer

Your TM1 system is getting slower. You notice it more and more every year. The obvious solution: more RAM, more powerful hardware, a new server. Sometimes that’s the right answer. Most of the time, it isn’t.

Before you invest in infrastructure, there’s another step you should take first: figuring out where your system is actually losing time.

Why Most TM1 Performance Issues Are Not Hardware Problems

In our ten years of TM1 consulting, we have conducted dozens of performance analyses. The results are remarkably consistent: In about 80 percent of cases, the problem does not lie with the hardware. It lies in one of these three areas:

• Individual TI processes that run longer than they should without anyone noticing. Often because they have evolved over time and were never optimized.
• Cubes in which data piles up in irrelevant coordinates. Versions that are long outdated. Scenarios that no one uses anymore.
• Rules that are more computationally intensive than necessary because they operate on aggregates or perform unnecessary lookups.

The common thread: You can’t identify these problems without data. If you optimize based purely on gut feeling, you’ll end up buying new hardware. If you work with data, you’ll optimize the right areas and often save tens of thousands of euros in infrastructure investments.

Three Ways to Improve TM1 Performance

Performance optimization in TM1 can be divided into three distinct levels. Each has its own levers and tools. If you confuse them, you’ll be optimizing in the wrong place.

Level 1: Process Performance

This concerns the runtime of individual TI processes: forecast runs, consolidations, data exports. These processes often run overnight, and no one pays attention to them as long as the reports are ready in the morning.

Typical causes of gradual deterioration: data volumes grow without the process accounting for it. Logic is expanded over the years without being refactored. Dependencies on other processes creep in.

What you need: runtime logs. For each process: when it started, how long it ran, and with which parameters. Over the course of weeks or months. Only then will you see trends.

Level 2: Cube Performance

This is about the data structure in the system. How much data is there, and where is it located? Which cubes are really large? Where are most of the values concentrated?

A classic scenario: A forecast cube has 10 versions, two of which are actively used. The other eight take up RAM and slow down aggregations. No one deletes them because no one is sure whether they’re still needed.

What you need: An overview of where the data is located. A dedicated analysis cube that displays data volumes per cube and per key dimension. This allows you to identify candidates for optimization in minutes.

Level 3: Rule Performance

The level with the highest impact and the highest complexity. A poorly written rule can slow down entire cubes because it has to perform calculations every time a value is retrieved.

Typical problems: Rules that operate on consolidation elements instead of on leaves. Lookups into other cubes without caching. Nested IF constructs that become linearly slower as the data volume increases.

What you need: Rule tracing tools that show which rules are executed and how often. Plus the discipline to measure performance before and after every rule change.

How to Find Performance Bottlenecks in Less Than an Hour

Before you even think about optimization, you need data transparency. Here’s the approach we take with our clients when the system has become noticeably slower:

1. Implement standardized process logging, if not already in place. Every TI process should log: when it started, who started it, with what parameters, how long it ran, and with what result. Effort: 1 to 2 days. This is the foundation for everything else.
2. Analyze runtime data from the last 30 days. Which processes run the longest? Which ones are executed most frequently? Which ones fit both criteria? These are your top candidates for optimization.
3. Perform a data scan for the two or three largest cubes. Where is the data located? Which versions, scenarios, and departments are active, and which are inactive? This often yields RAM savings of 10 to 30 percent within an hour.
4. Track rule performance via the TM1 Operations Console or server logs. Which rules are triggered most frequently? Are they written efficiently? This check requires experience, but the potential impact is significant.
5. Only then should you consider hardware. If you’ve thoroughly addressed steps 1 through 4 and the system is still slow, you now have the data you need to make an informed hardware decision. It’s likely to be smaller than you might have thought.

How this works in practice

In 2024, an industrial client came to us with a clear request: “We need more RAM; the system is too slow.” Before ordering any hardware, we spent two days focusing on logging and data transparency.

We call the tool behind this “process logging.” It adds a standardized log line to every TI process. Effort required: 2 days for implementation; after that, it runs automatically.

The analysis after 14 days revealed:

• A forecasting process that had taken months to grow from 8 to 35 minutes. Cause: a subset that was regenerated every night, even though it had barely changed. Optimization: 30 minutes of work.
• Three cubes containing obsolete data – versions from 2019 that no one needed anymore. RAM savings after cleanup: 12 percent.
• A rule that calculated over 50,000 cells for every report query because it was unnecessarily operating at a higher aggregation level. After refactoring: reports 70 percent faster.

Result: No hardware investment required. The system runs faster than it did two years ago. The logging tool’s ROI in the first year: approximately 284 percent. Plus the hardware investment that wasn’t made – that wasn’t even factored in.

Conclusion

Improving TM1 performance is rarely a hardware issue. It’s usually a matter of data transparency. Unless you can see in numbers where your system is losing time, you’re optimizing in the dark. With logging and targeted cube analyses, you can identify the real bottlenecks in just a few days. The optimization itself is often the easier part.

Anyone who buys hardware without a data foundation is treating the symptom, not the cause. And they’ll be back three years later with the same problem.