How to analyze ST12 ABAP trace to tune SAP program performance

You are asked to work on a SAP ABAP program to make it run faster. You are following the performance process discussed in the post – SAP ABAP program performance tuning process. You have used SAP ST12 transaction to trace program execution. Now you are wondering how to understand SAP ST12 traces collected and do the performance analysis to find out specific performance tuning opportunity. This post would cover:

  1. How to understand ABAP trace of ST12 and
  2. How to analyze ABAP trace for performance tuning.

SQL trace of ST12 would be discussed in separate post.

1 Understand data in SAP ST12 ABAP trace screen

Again, here I assume that you know how to navigate through ST12 trace. SAP ST12 has following evaluation options

Figure 1 – ST12 traces

ST12 trace analysis has two main components normally: ABAP trace and performance(SQL) trace

Click “ABA Trace” button, you would get ST12 ABAP trace screen like:

Figure 2 ABAP trace screen

The above screen has two parts vertically – the upper part is overview of runtime distribution. The time distribution tell you program runtime distribution among CPU(ABAP), Database and system. In the figure-2, The program spends 62% of runtime on ABAP operation. The lower part is a hit list showing runtime distribution among ABAP components. Hit list is sorted on “gross time” by default. But you can sort it on other column based on your analysis need.

Now you wonder what are those columns “Call” etc in SAP ST12 ABAP trace screen meaning. Please refer to table 1 for details:

Table 1 Understand ST12 ABAP trace data




Specific operation executed captured in the trace – can be a simple ABAP statement or a form/FM etc.


number of times which the object in “call” column is actually executed during the trace.


total time which “call” takes to execute “No.” times.


time spent by direct ABAP/SQL statements in object under “call” column. For simple ABAP statement – Gross = Net. for a “function module”, “Net” time is a sum of time spent by all direct/simple ABAP/SQL statements in object under “call” column.


Gross/total-runtime X 100%.


Net/total-runtime X 100%.


Where the “call” is from.


Default “blank” – Call is an ABAP operation.

“DB” – call is aSQL operation.

“SYS” – call is a system operation.

2 Analyze ABAP trace

2.1 Identify “silver bullet” from ST12 ABAP trace

In my experience, performance issues are often caused by top expensive ABAP statements in the program. Addressing those individual ABAP statements usually improve a program performance greatly resulting in meeting business performance requirement. Those top expensive ABAP statements are what I called “silver bullet”.

If you sort SAP ST12 ABAP trace screen by “Net %” column descending, then most expensive ABAP/SQL statements would show up at top of display like below:

Figure 3 ST12 ABAP trace sorted by Net%

To review corresponding ABAP source code detail, you can place the cursor on the line, then click icon in SAP ST12 ABAP trace screen. For example, I click once on 2nd line -“Select LIPS”, then I click . It shows program name, exact source code info as below

Figure 4 – Sample Source code related to ABAP trace

If you have ABAP knowledge, you can understand why the statement is so expensive in its’ context, like sort a unchanged table in a loop etc. Application knowledge with insight on testing case can help you to identify problem and solution quickly, For example, if the testing case is to create one sale order, but top expensive ABAP statement is to read order header table VBAK many times, then this is definitely a design or coding issue.

For “DB” type of call, it would show corresponding SQL summary screen for that location if you click on the link . See following example for Call “Select LIPS”.

On the above screen, you would find important information like program, location, number of execution, number of records etc needed in performance analysis. You also can get SQL execution plan from here. I would cover more in SQL analysis of SAP ST12 trace.

Following is a list of common scenarios on expensive ABAP statement from my experiences:

Table 2 Typical ABAP performance concerns and their solution


Likely solution


Wrong technique to read internal table

Sort, binary read, using table index.

How to read a table would make “material difference” for a big internal table.

Too many read on internal table from different places

Combine multiple read statements.

Reduce un-necessary visit on the same table.

Sort a table repeatedly

Avoid un-necessary sort.

Sorting a table in a loop or sorting the same table at different locations is an “enemy” for performance.

Too many individual operation on internal table like modification etc

Use mass operation related to internal table.


Loop on internal table

Reduce loop, combine loop etc


Expensive SQLs

Reduce # of execution, use ‘right’ index, buffer table/data etc.

More details in ST12 SQL trace analysis section.

Others like sleep, wait event

Avoid synchronous RFC calls and hard coded wait and sleep etc.



Tuning remote executed FM/program.



I would like to point out no matter how efficient a code is, it should not be executed if it is not needed by business. So we should try to avoid executing the code instead of improving the code in such situation. This has been covered below as a separate point for subroutine/form but the idea is applicable here as well.

2.2 Identify extra “subroutine” call based on ST12 ABAP trace

Hopefully, by addressing expensive ABAP statements, the program performance meets requirement. If there is no “silver bullet” detected in ST12 ABAP trace and program performance is short of expectation, what we should do next?

Now, we should pay attention to ABAP subroutines (forms and Function module) calls, we should consider following points–

  • Whether the program needs to execute the subroutine.
  • Whether number of times which the subroutine is executed by the program is justified by business/functional need.

I think you remember our focus is top expensive subroutine calls in this type of analysis.

Figure 5 ABAP trace – validate number of execution

You need application-level knowledge to assess above points. If one function module takes 60 minutes for two executions, it might reduce runtime 30 minutes when number of execution is one. If we remove the function call, it would save 60 minutes.

In my performance tuning experience, I found that a logic/subroutine developed for one country was executed “un-necessary” in another country’s business process, this contributed to performance issue. In another scenario, I found a logic which should be executed once on SAP document head level was executed at line item level – this means if the logic would execute 100 times if the document has 100 line items even the logic only need to execute once for the whole document.

You can use “Call Hierarchy” button to do top down analysis to see where time is spent or bottom-up to see where the call is from. You might find this useful. But I seldom find the need to do this type of analysis.

After all above works (including SQL analysis), performance of the program is normally greatly improved and meets user’s expectation. However there are cases that we cannot meet performance tuning goal and no more meaningful tuning opportunity with all above effort. Then what? Please continue reading.

2.3 Review Program Design and Configuration

Now you can analyze general performance and try to find out what you should do to improve the performance.

You can open ABAP trace summary screen to get an overview of performance on the program execution by clicking “ABAP Trace Summary” button. This would show runtime distribution of program execution. The relation among them is total runtime = database time + ABAP time + system time. Total runtime showed up in ST12 should be almost similar to actual program runtime. If there are big difference between ST total time and actual program runtime, this can be related to setting of ST12 when you did the trace and operating system and the quality of trace might be jeopardized. You might wish to redo the trace.

Please be advised this CPU time is actually the time which the program spends in ABAP logic side which can includes “wait” time not the actual CPU time which the server spends during the program execution.

System time should be minimal – normally under 1%. If this is high, then you need to review system status. You might need to redo the trace when the system is in normal load status.

There are other views like Summary per application component etc.

With overview information from ST12 ABAP summary screen and top expensive subroutine information from ST12 ABAP trace screen, you should be able to establish function area which creates the performance bottleneck. At this point, we need to review program design and underlying function configuration to make performance improvement. Our customer order loading program performance was greatly improved after SAP SD price procedure is simplified such as reducing number of price group and optimizing access sequence via pre-step etc.

Performance issue can be due to overall solution design. In one case, I was asked to approve index request for a local report which mainly produces supply/demand picture for selected materials, It took 10 minutes to give the picture for a single material. To fix this, developer planned to create two indexes on two different SAP tables. In my experience, I know that this local report is similar to standard MM transaction MD04 which takes seconds to return similar result. That information is shared with developer. The program was leveraged related logic from standard SAP MD04 design and performance issue was addressed without creating new indexes.

Coming to this point, the program should be able to meet performance requirement in most cases. However, if performance of transaction still falls short of expectation due to volume, what is next step to make program to meet the performance requirement.

2.4 Break-down the job and Use parallel processing

After all those effort , if the performance is still a concern, there is no ABAP/SQL coding issue, there is no function configuration concern, the design is ideal but performance is still short of the expectation. Now we should consider breaking down the work to smaller tasks which can be handled by multiple processes at the same time – this is called parallel process. Bottom-line is that we should only consider parallel solution when underlying program has a sound design and performance has been well tuned. I would write a post about parallel processing in the future.

2.2 SQL Trace Review

This is to fix inefficient database access based on SQL Summary screen from SAP ST12 “performance trace”, following is SQL summary screen…

If performance trace shows that program spends most of time on database side, it is critical to analyze program performance/SQL trace to identify improvement opportunity. Please Click here for my subsequent post on how to analyze SAP ST12 SQL trace to tune SAP program performance.

2 thoughts on “How to analyze ST12 ABAP trace to tune SAP program performance”

Leave a Reply