Show TOC

Finding Hot Spots with the HitlistLocate this document in the navigation structure

Prerequisites

You have traced your ABAP program either Tracing an ABAP Program or by Scheduling a Trace. Your trace can be made from the ABAP Developer Tools or from transaction SAT in the integrated SAP GUI.

Context

Use the ABAP Trace Hitlist to do the following:

  • Analyze the runtime of your ABAP application - how long does it take to run?
  • Find performance hot spots – operations that cost disproportionate amounts of runtime and which perhaps could be optimized.

The Hitlist aggregates trace events (potentially costly ABAP statements and events). This means that you can easily see runtime accounted for by repetitive events in your program, such as repeated calls to a particular method. And you can evaluate the impact of aggregated operations on the total runtime of the application.

Here is how to use the Hitlist to evaluate potential hot spots in an ABAP program.

Procedure

  1. Open the Hitlist by selecting a trace in the ABAP Traces view and choosing Display Trace Hitlist from the context menu.

    The Hitlist opens in a new view of its own. It starts with the list of trace events sorted by Own Time. That is the run time in microseconds that was spent in the trace event itself, excluding other trace events (such as procedure calls) made during the trace event. A method may have a large total time but a small own time if it does nothing but call another method.
  2. Here's how to read this excerpt from a hitlist, sorted by Own Time. We want to evaluate the importance of the top entry in the Hitlist, SELECT SINGLE TLDOC_ITFPARACONV. This trace event accounts for fully 25 percent of the runtime of the traced program – that qualifies it as a 'hot spot' – a target for potential optimization. We'll pay special attention to the Own Time and Hits columns. Here is Understanding the Trace Fields for understanding all of the columns.

    • The Trace Event column shows what ABAP operation was recorded. Here, the topmost, most expensive trace event – Select Single TLDOC_ITFPARACONV – belongs directly to our own program, the program that we want to analyze. Since the trace event belongs to our code, we can potentially optimize it. The next two lines – Fetch ICFSERVICE – pertain to the ABAP HTTP service infrastructure. They are not directly part of our program, and we can ignore these trace events. The Called Program and Calling Program columns help you to recognize events that belong to your code and non-relevant trace events that belong to the ADT infrastructure.
    • Own Time (Microseconds) shows the accumulated time spent doing the traced operation. Own Time is important because it is the time spent doing the operation by itself, without counting any time the operation may have spent waiting for other traced operations that it called. Here, our program spent 37 milliseconds reading single entries from a database table called TLDOC_ITFPARACONV. The Hits column shows how many individual trace events are aggregated in this trace entry. In our example, there were 31 SELECT SINGLE operations on TLDOC_ITFPARACONV.
    • Own Time (%) lets you assess the impact of this aggregated operation on the total traced runtime. 37 milliseconds is not a lot of runtime, but, on the other hand, the SELECT SINGLE operations account for 25% of the total runtime of the traced program. So optimizing this database operation could have a big impact on the performance of the application as a whole.

Results

Armed with this information, you can now decide whether this top entry in the Hitlist deserves optimizing attention or not. On the one hand, 37 milliseconds is not a lot of time. On the other hand, it is a full quarter of the total runtime of the traced program.

Since the operation is a database operation, there are several low-cost optimization strategies available.

  • We could check whether caching in switched on for TLDOC_ITFPARACONV, and if so, whether the caching strategy is correct for the table and its use.
  • Are the same records being fetched over and over again? If so, then perhaps the program could fetch each record only once.
  • Are all of the fields of the table records being used? Perhaps only a couple of fields need to be fetched.
  • If the table is small and most or all of the records in the table are being read, then perhaps the program would be more efficient if it did a single SELECT of the table contents into an internal table.

Should you wish to take a closer look at the code or set a break point in the code, just double-click on an entry. The ABAP editor opens in a separate window, positioned where the aggregated trace event occurred.

Note

You can also use these context menu functions to navigate from hit list entries: