Skip to Content

A Tool to Compare Runtime Measurements: Z_SE30_COMPARE

This Web log introduces the report Z_SE30_COMPARE, which can be used to compare ABAP Runtime Traces. Comparing traces can be interesting in many respects; for example you might want to evaluate the runtime effects of your recent coding update. However, the main task this report supports is a linearity check in the performance standard. With this report it is possible to identify nonlinear coding with two SE30 traces of rather small test cases.

1. Introduction

In the previous Web log Performance Problems Caused by Nonlinear Coding we discussed different issues concerning nonlinearity. In this Web log we provide the source code and explain the basics of how to use the report. For more details about the nonlinearity check, we recommend another Web log, Nonlinearity Check Using the Z_SE30_COMPARE.

This Web log is a step-by-step guide for the basic usage of the Z_SE30_COMPARE. In the following sections we will discuss:

  1. Introduction
  2. The Source Code of the Report Z_SE30_COMPARE
  3. First Test with Two Example Hit Lists 
  4. How to Create Traces
  5. Download the Hit List
  6. Comparison Scenarios
  7. List of Features (regularly updated)
  8. List of Changes (regularly updated)


2. The Source Code of the Report Z_SE30_COMPARE

To be able to run the report, you must first copy the following coding to your system and store it as a local object. The report does not have to run in the same system where the traces are executed. However, if the traced program is in same system then it is possible that you can directly navigate to the source code of a traced operation.


*** The coding can be found as a Code Snippet under my name ***


For better usability we recommend that you add the selection texts as shown here. (Expert users will be able to work without selection texts.)

Now you can save the report, run a syntax check and activate it. When you then call it from transaction SE38, you get the following initial screen:


3. First Test with Two Example Hit Lists

Here you get two small hit lists, which allow you to run a simple function test of the report. The lists have been reduced to the top 10 lines, just to show the basics of the report. A regular hit list can have several thousand lines.


Copy the two files into notepad and store them on your own PC as files ‘Test_100.txt’ and ‘Test_1000.txt’. Make sure that the file path is not too long (path and filename should be no longer than 140 characters). When you have stored the files, you can start the report and select the files from your PC using the selection screen.

The result of the default function ‘Show Details with Ratios’ should be:

If it doesn’t work, check whether the files have been corrupted by your editor or whether tabs and returns have been added.

From the hit list, only 6 columns are processed: the program, line, call, no, net, and gross. The blue columns are the key fields; these are calling program and calling position (from program and line) and call-class, call-type, and call-name (all from the original field ‘call’). Lines with identical values from both traces are identified and shown together. The green column ‘Code’ shows ‘T1’ or ‘T2’ for trace 1 and 2, respectively, if no counterpart is found. The other codes ‘CL’, ‘IL’ and ‘C0’ indicate compare success.

The yellow, white and orange columns display the values for net times, executions (no) and gross times from both measurements. Additionally, the ratios, i.e. ‘value2 / value1’ are shown. The start-screen offers also the possibility to display differences ‘value2 – value1’.
After you have run this test successfully, you might want to compare your own traces.

4. How to Create Traces

For an introduction to the ABAP Runtime Trace (SE30) we recommend that you read the Web log The ABAP Runtime Trace (SE30) –  Quick and Easy. After you have read the Web log, it should be easy to produce your own trace files.

The mains steps in the process are:
0. It is very important to choose your test case carefully. Your analysis can be only as good as your test case. This means that your test case should be typical for your application.  

  1. Call the ABAP Runtime Analysis (SE30). Open the SM50 in a separate mode and check what is going on in the system. If there is a really high load on the system, then it is better to take the measurements later, when there is less traffic on the system. If this is not possible, then you should at least be aware that the measurement quality may not be very high. 
  2. Go to measurement restrictions and create a new one with the name ‘by_call’ for your user. Check the settings on the three tabs and change them if necessary:
    a. Program (parts): nothing should be selected in the table.
    b. Statements: Select nearly everything, but not the internal table operations and not the kernel-level runtime administration.
    c. Duration/type: Set the maximum file size to 20.000kB and choose aggregation ‘per Call Position’.
    Save this setting. We recommend that you create two additional measurement restrictions under your user for later usage:
    a. With the name ‘by_call_itab’, identical to ‘by_call’ but with internal tables activated on the statement tab.
    b. With the name ‘no_agg’, identical to ‘by_call’ but with aggregation ‘none’ on the last tab.
  3. Trace your first test case. Note, when your program is finished, you must go back to the initial screen of the SE30 to finish the measurement.
  4. Repeat the measurement several times for test case 1. We highly recommend that you run every test case at least three times and trace all executions. Usually the first execution is slower, because buffers and caches must be filled. The second and third executions should need similar times. If this is the case, then you can continue with the knowledge that you are working with reproducible data.
  5. List the files with the button ‘Other File’ from the block ‘Measurement Data File’ and display your measurements one after the other.  
  6. Note the total time and the system time. A high system time indicates that the trace file contains many system operations, such as ‘Load’ and ‘Generate’, which is not a very useful trace. Check the three or more executions of your test case. It is quite normal that the first execution is slower, but the others should not vary more than 5 to 10%. Mark the fastest trace and display the hit list for download.

Repeat steps 3 to 6 for the second test case.

5. Download the Hit List

From the hit list there are only three more steps to get the downloaded trace file. As there are often misunderstandings with these steps, I have listed them in detail:

Step 1: Change the layout
It is necessary to add the column ‘line’, if you want to display the source code or if internal table events shall be compared. Therefore, the layout of the hit list display must be changed. This is only possible for traces with aggregation ‘by call’, as other traces are displayed slightly differently by the SE30.

The mandatory columns of the hit list are ‘Number’, ‘Gross (time)’, ‘Net (time)’, ‘Call’, and ‘Program Name’. Additionally, ‘Line’ is highly recommended; it is necessary if you want to compare internal tables or if you want to navigate directly to the source code. All other columns are ignored by the compare report. The resulting hit list should look like the following example:

Step 2: Display everything – switch off all filters
Filters are useful for the cumbersome list output of the SE30, but the compare report uses a powerful ALV output, and therefore it is better to see everything in a very fine granularity. In specific situations, it is possible to deviate from this recommendation. However, it is absolutely necessary that both of the hit lists being compared have identical filter setting.

The example above is a hit list with a default filter. The following shows that leaving off any filter settings allows you to see additional important information:

Step 3: Download the hit list to your PC as unconverted txt file
This step is very often misunderstood. You should not store the binary trace file, but the displayed hit list. And the hit list should not be stored as spreadsheet, but as an unconverted text file.

The trace file must be stored on your PC in a directory of your choice. Make sure that that path and filename together do not exceed 140 characters. The trace file should look like the examples in section 3. 

6. Comparison Scenarios

Comparisons are useful in the following scenarios:

  • Program Versions: The program has changed and you want to figure out the effect of the changes on the runtime.
  • System Influence: Program and data are identical, but the program runs in different systems with different hardware. What is the effect on the runtime?
  • Statistical Variations: We highly recommend that you run once the same program with the same data in the same system. The results will show you the statistical variations between measurements, which gives you a better feeling about the reproducibility of measurements.
  • Nonlinearity Check: Program and system remain unchanged, the amount of processed data changes. This is the main use case for the report, because this check is necessary if you want to know whether your program scales linearly. Details about the nonlinearity check can be found in another Web log Nonlinearity Check Using the Z_SE30_COMPARE.

The first three scenarios are straightforward. There you probably want to see the results with differences instead of ratios. Ratios are useful for the ‘Nonlinearity Check’, which is also the only case, in which the parameters N1 and N2 are relevant.

In the case ‘Program Versions’ where the coding was changed, it can happen that many lines cannot be identified anymore, because the coding position or the name of the call has changed. The function ‘Show Uncomparable Lines’ displays only the lines with code ‘T1’ or ‘T2’ with the following order of the key fields: call-class, call-type, calling program, calling position, code and call-name. In that setting you will easily recognize if there is a small offset in the calling position or if the call-name has changed. If the calling position is not comparable anymore, then a comparison with the setting ‘Full Aggregation’ can be useful.

Now you should be able to run some comparisons with your own trace files. For the nonlinearity check I recommend that you also read also the Web log Nonlinearity Check Using the Z_SE30_COMPARE.

7. List of Features

Some of you might know the program from previous versions. However, since the functionality has been continuously extended and improved, you may want to take a look at the current features:

  • The report can compare two downloaded hit lists and displays the result as ALV list. It can be used for nonlinearity checks (use ‘Ratios’) and for comparison of different program version, systems, statistical variations etc. (use ‘Differences’).
  • The report can recognize all known layouts of the SE30 hit list of all currently supported releases. The layouts can even be changed manually.
  • If the trace is aggregated ‘by call’ and the calling position of the call is added to the layout (see above), then internal tables can also be compared efficiently. Note that internal table operations are aggregated by calling position independently of their technical name, i.e. for example ‘it001234’ before the comparison is done. This aggregation is not performed in transaction SE30.
  • If the calling position is included in the download and the report ‘Z_SE30_COMPARE’ runs in a system where the source code of the traced program is available, then a double click in the ALV list displays the source code. This works fine as long as the source code was not changed.
  • While the standard setting for the aggregation is ‘aggregated by call’, the report is able to deliver a full aggregation if needed.

8. History of changes

    Jan 2008: Release of this web log together with program version 2008_01

This web log provides a report which is able to compare SE30 hit lists. It is explained in detail how the trace files must be prepared and downloaded when they shall be used as input for the report. A further web log will introduce the main use case of the report, which is the check for nonlinear coding. Nonlinear coding is a major source of performance problems.

Further Reading: Performance-Optimierung von ABAP-Programmen (in German!)

More information on performance topics can be found in my new textbook on performance (published Nov 2009). However please note, that it is right now only available in German.


Chapter Overview:

  1. Introduction
  2. Performance Tools
  3. Database Know-How
  4. Optimal Database Programming
  5. Buffers
  6. ABAP – Internal Tables
  7. Analysis and Optimization
  8. Programs and Processes
  9. Further Topics
  10. Appendix

In the book you will find detailed descriptions of all relevant performance tools. An introduction to database processing, indexes, optimizers etc. is also given. Many database statements are discussed and different alternatives are compared. The resulting recommendations are supported by ABAP test programs which you can download from the publishers webpage (see below). The importance of the buffers in the SAP system are discussed in chaptr five. Of all ABAP statements mainly the usage of internal tables is important for a good performance. With all the presented knowledge you will able to analyse your programs and optimize them. The performance implications of further topics, such as modularisation, workprocesses, remote function calls (RFCs), locks & enqueues, update tasks and prallelization are explained in the eight chapter.

Even more information – including the test programs – can be found on the webpage of the publisher.

I would recommend you especially the examples for the different database statements. The file with the test program (K4a) and necessary overview with the input numbers (K4b) can even be used, if you do not speak German!

1 Comment
You must be Logged on to comment or reply to a post.