Performance Suite – ABAP Debugger – Part 3
This tool is used to identify errors in programs.
Note that processing may terminate during debugging, which will automatically trigger a database commit. In this case, the work process (the LUW) is interrupted and this may result in some data inconsistencies (see Note 859240). We therefore recommend that you only debug the test system, if possible.
Performance analysis using the debugger begins when you start the program to be examined. In the second session, you start the work process overview (Transaction SM50, see below). From the work process overview, you choose the Debugging function to navigate to the debugger. By repeatedly navigating to the debugger in quick succession, you can identify the sections of source code in the program that have a high CPU requirement. Experience has shown that these are often LOOP..ENDLOOP loops over large internal tables.
The following programming errors always result in a high main memory and a large CPU requirement:
- Missing REFRESH or FREE statements
You use these statements to delete internal tables and release the assigned main memory. If these statements are missing, resources are blocked unnecessarily.
- Reading in internal tables:
The READ TABLE..WITH KEY.. ABAP statement without a further addition triggers a sequential search. This is very time-consuming if tables are large. Performance is improved considerably if the system uses the ..BINARY SEARCH.. addition to read the table. For this, however, the table must be sorted beforehand. You can also optimize the performance of operations on large tables, for example, by using sorted tables (SORTED TABLE) or hash tables