Rank by Runtime Times Frequency: Find Your Top SAP Fixes

The Slow Report Is Rarely the Real Problem
Fixing what feels slow is not the same as fixing what costs the most. A report that takes four minutes once a month annoys one finance manager. A 300-millisecond lookup that fires two million times a day quietly eats your database. Teams chase the first and ignore the second.

This habit is common, and it is expensive. Users complain about the dramatic waits they can see, so those waits land at the top of the backlog. Meanwhile the real drain runs untouched in the background, because no single call looks slow enough to notice. Measurement-led SAP HANA Performance Optimization flips that habit, and 2isolutions US, an SAP partner delivering since 2005, builds its method around the flip.

The idea is simple to state. Stop asking which programs feel slow. Start asking which programs cost the most in total. Those are different lists, and only one of them tells you where to spend your effort.

What Does Ranking by Runtime Times Frequency Actually Mean?
Ranking by runtime times frequency means multiplying how long a piece of code takes by how often it runs, then sorting the results from highest to lowest total cost. The top of that list shows where your system spends its time. Everything below it matters far less.

The concept sounds obvious, yet most teams never apply it. Instead, they fix whatever users complain about loudest, or whatever a developer remembers being slow. Neither approach reflects what the database actually experiences.

Consider two examples. A custom report runs for 240 seconds and executes twice a week. Its weekly cost is 480 seconds. A small pricing routine runs for half a second but fires 800,000 times a day. Its daily cost is 400,000 seconds. The routine costs far more, yet nobody complains about it because each call feels instant.

That gap explains why user complaints make a poor priority list. Users notice latency. They don't notice load. Your database notices only load.

Why Perception Misleads
Human attention locks onto the single long wait. Aggregate cost stays invisible without tooling. As a result, teams spend weeks tuning dramatic but rare slowdowns while the real drain keeps running in the background. The four-minute report gets a project plan. The half-second routine gets nothing, even though it consumes thousands of times more resource.

Fixing this does not require a new philosophy. It requires numbers that capture both dimensions at once: how long each call takes and how many calls happen. Once you have both, the ranking almost builds itself.

Why Does the First Week of Measurement Deliver the Biggest Gain?
The first week delivers the largest gain because cost is never spread evenly across your code. A small group of objects usually accounts for most of the total runtime. Measurement finds that group fast, so early fixes remove the biggest burden before effort starts to taper off.

Think of it as a steep curve. The first few items on a ranked list carry enormous weight. By the thirtieth item, you are polishing code that barely registers in your workload traces.

This is the core argument behind the approach. You don't need months of analysis to find the heavy hitters. A focused week of measurement, ranked correctly, points to the changes that move the numbers.

Teams that skip measurement often work the other way around. They start with a long wish list, assign it by seniority or noise, and burn the first month on low-yield items. Then the budget thins out right when the real problems surface. The order of work matters as much as the quality of the work.

Here is what a measured first week usually produces:

A ranked list of the most expensive programs, functions and SQL statements
Clear evidence of which anti-patterns drive that cost
A baseline runtime for every candidate fix
A defensible order of work that finance and IT leaders can both read
That baseline matters most. Without it, you cannot prove any later improvement. A claim that something feels faster carries little weight in a budget meeting. A recorded before-and-after runtime carries a lot.

How Does the Five-Step Method Work in Practice?
The method has five steps: Measure, Analyse, Rank by runtime times frequency, Rewrite with HANA pushdown, and Prove with row-by-row parity and before and after runtimes. An architect reviews every change before it moves to transport. Each step feeds the next, so nothing gets rewritten without evidence.

Here is the sequence in order:

Measure. Capture real runtimes and call counts from your production-like workload, not from a developer's test run.
Analyse. Trace the expensive objects to the exact statements and loops that cause the cost.
Rank by runtime times frequency. Sort every candidate by total cost, not by how slow it feels.
Rewrite with HANA pushdown. Move the heavy logic into the database, where it runs on the engine built for it.
Prove. Compare output row by row against the original, then record before and after runtimes.
The discipline in this sequence is what separates it from ad hoc tuning. Nothing gets rewritten until measurement says it should. Nothing ships until the output matches the original row for row. And an architect signs off before any change moves to transport.

That last point deserves attention. Performance work carries a risk that is easy to underestimate: a faster program that returns slightly different results is worse than a slow one. Row-by-row parity removes that risk. It gives business owners confidence that the numbers they rely on have not shifted, even though the code underneath has changed completely.

Where Does AI Fit Into This Picture?
Ranking is a data problem, and data problems suit automation. Collecting runtimes and call counts across thousands of objects, tracing them to statements, and sorting by total cost is tedious work for a human team. It is exactly the kind of work that SAP AI Solutions can accelerate, because the inputs are structured and the goal is clear.

The pattern works best when AI handles the heavy lifting of finding and ranking candidates, while experienced architects handle judgment. That division keeps speed high without giving up accountability. The machine surfaces the highest-impact items. The people decide how to rewrite them and confirm that the results hold up.

This is also where SAP AI Integration becomes practical rather than theoretical. Embedding measurement and ranking into the way your team already works means the list of top fixes stays current instead of going stale after a one-off review. Workloads change. New custom code gets added. A ranking that was accurate last quarter may miss the new heavy hitter this quarter.

Looking further ahead, Agentic Ai SAP approaches point toward systems that do more than report. They can propose candidate fixes, run comparisons and prepare evidence for human review. The principle stays the same either way: evidence first, change second, proof last. Automation speeds up the evidence. It does not replace the review.

What Should You Do Differently Starting Now?
You do not need a large program to benefit from this thinking. A few changes in habit make a real difference, even before any tooling arrives.

Stop treating user complaints as your priority list. Treat them as one input among several.
Ask for call counts alongside runtimes. A runtime without a frequency tells you very little.
Record a baseline before touching anything, so every improvement can be proven.
Insist on parity checks for every rewrite, so speed never comes at the cost of correctness.
Work the ranked list from the top, and resist the pull of the long wish list.
These habits cost little to adopt. They also change the conversation between IT and finance. Instead of debating which complaint is most urgent, both sides can read the same ranked list and agree on the order of work. A defensible order reduces friction, and it protects the budget for the items that matter most.

FAQ
Q: What does ranking by runtime times frequency mean?

It means multiplying how long a piece of code takes by how often it runs, then sorting by total cost from highest to lowest. The top of the list shows where your system really spends its time, which is often different from what users complain about.

Q: Why is the first week of measurement so valuable?

Cost is rarely spread evenly. A small group of objects usually accounts for most of the total runtime, and a focused week of measurement finds that group quickly. It also produces a baseline runtime for every candidate fix, which lets you prove later improvements.

Q: How do you make sure a rewrite does not change business results?

The final step of the method is to prove the change. Output is compared row by row against the original, and before and after runtimes are recorded. An architect also reviews every change before it moves to transport.

Conclusion
Fixing what feels slow is not the same as fixing what costs the most, and ranking by runtime times frequency is how you tell the two apart. A measured first week, a five-step method and row-by-row proof turn tuning from guesswork into a defensible plan. Put evidence ahead of opinion, and your highest-impact fixes rise to the top on their own.

Ready to find the fixes that actually move your SAP numbers? Our experts are here to help you measure, rank and prove every improvement. Contact us at [email protected] to get started today.