Finding Performance Hotspots with the ABAP Runtime Analysis

Finding Runtime and Memory Hotspots in Measurements

Here is the procedure for scanning code for runtime or memory hotspots.

1. Start the ABAP Runtime Analysis by entering transaction SAT or choosing  System  Utilities  Runtime Analysis  Execute. 

2. Specify a variant that has Aggregation set to None.

   The resulting 'ABAP trace' measurement records trace events individually, so that you can search for particular ABAP statements.

   If you want to scan for memory hotspots, then set the option Measure Memory Use in the variant.

   Optionally, you can turn the trace on and off on your own. Do this if you know the part of an interactively started program or transaction that you want to trace. You can then limit the trace to the relevant part of a program or transaction.

3. Start the non-aggregated measurement (ABAP trace) using any of the three Runtime Analysis start methods.

4. Display the trace when it is done, if it is not displayed automatically.

   You find yourself on the tab Desktop 1, which is set up by default for analyzing performance.

   Switch to the tab Desktop 2, where you find tools for analyzing program flow, the Call Hierarchy and the Processing Blocks tool.

5. Scan the measurement for runtime or performance hotspots. Switch to the Processing Blocks tool. Then click .

   The Runtime Analysis opens a dialog box for customizing the hotspot scan.

6. Decide which of the three scans you would like to use.

   Here is how you can use each scan:

   • Percentage of Total Runtime (Gross): Find out where your program spent most of its clock runtime.

     The scan marks the processing blocks (method, function module, form routine calls and the like) with start to finish elapsed times (gross runtimes) that are over the limit you specify.

   • Percentage of Total Runtime (Net): Find the processing blocks in which your program used runtime most intensively.

     The scan marks processing blocks which were large net users of runtime, not counting any other processing blocks that were called within them.

     Start with a high specification in the LimitVal field, such as 20%. That way, you can see quickly whether there are highly intensive net users of runtime.

     Note

     Gross Runtime is simply the elapsed time between the start and end of a processing block. Net Runtime is usually more useful, because it does not count runtime spent in other processing blocks. Net Runtime is only the time spent processing code directly in a processing block.

   • Memory Increase in Processing Block: Find the processing blocks that are conspicuous consumers of memory. The Runtime Analysis measures memory in use at the start and end of each processing block. It can therefore calculate how memory use changed during the execution of a processing block.

     The scan marks processing blocks which may contribute to any memory-related problems you are analyzing.

   The Processing Blocks tool marks any processing blocks found by the scan in red. It also opens the call stack to each such processing block.

7. Once you have found memory or runtime hotspots, use the other tools of the Runtime Analysis to analyze them.

   Here are some ways to find out why a particular processing block is a large user of net run time or of memory:

   • Tell the Runtime Analysis to display only trace records relating to a hotspot. To do this, put the cursor on the hotspot in the Processing Blocks tool. Then choose from the tool bar of the Processing Blocks tool.

     The Runtime Analysis tools now display only trace records that pertain to the hotspot.

     You can now work with this set of trace records as though it were the entire measurement. You can for example look for hotspots again within the hotspot processing block. You can also examine the processing in the hotspot in detail in the Call Hierarchy or Times tools. You don't have to worry about where the records of the hot spot begin or end in these detailed displays.

   • Switch to the Call Hierarchy or Times tools to see the detailed trace of processing in the hotspot. Mark the hotspot, and choose the function that you want to use from the context menu.

     Note that the net run time that you see will differ between the Processing Blocks tool and the other tools. This is because the Call Hierarchy and Times tool present much more detailed measurement data. The net runtime of the hotspot is therefore divided up among the subsidiary trace records of the hotspot.

   • Jump into the source code from detailed records in the Call Hierarchy or Times tools. You can analyze the source code to understand why individual operations in the measurement are expensive in runtime or memory consumption.

     You can also leave breakpoints or set up watchpoints if you want to reproduce the problem in the debugger.

Try It Out: Look for Hotspots in the Object Navigator (Transaction SE80)

In the Object Navigator (transaction SE80) of the ABAP Workbench, some people have observed that expanding the BASIS development package takes longer than expected. It may take up to two seconds for the second level of the BASIS hierarchy to open.

This slight performance problem offers a good example for performance analysis in practice.

To analyze the suboptimal performance, apply the procedure above to the following function.

1. Start transaction SE80 using the In Dialog start method of transaction SAT.

   Use a variant in which you have set the option Explicit Switching On and Off of Measurement.

2. Set the selection fields in the left-hand side to Package and BASIS.

3. Turn the trace on, measure the operation Expand All Nodes (button in the selection tool bar), and turn the trace off again.

4. Display the trace.

Tips for doing the analysis:

• Look for hotspots that consume 20% or more of the net runtime of the measured operation.

• Take a look at the code in the hotspot that you find. The high resource usage most likely comes from the loop in loop construction in the code.