Best Practice for ABAP Performance and Tuning

Performance Tuning in ABAP

Summary  

ABAP Performance and Tuning – This Article describes the Performance tuning in ABAP, how to optimize the ABAP code and various tools used for performance tuning. 

What is performance tuning? 

Performance tuning is to anticipate, identify, analyze, and solve performance problems to keep the SAP system on top, i.e. to make the SAP system run quickly and efficiently. 

Steps to optimize ABAP Code: 

DATABASE 

1. Use WHERE clause in SELECT statement to restrict the volume of data retrieved.  
2. Design the Query to Use as much index fields as possible in the WHERE statement 
3. Use INNER (or OUTER under some circumstances) JOIN in your SELECT statement to retrieve the matching records at one shot 
4. Avoid using nested SELECT statement and SELECT within LOOPs, better use JOINs or FOR ALL ENTRIES. Use FOR ALL ENTRIES when the internal table is already there or the end of some processing. Try JOINs if the SELECT are right behind each other 
5. Avoid using INTO CORRESPONDING FIELDS OF TABLE during buffered access. Otherwise use the most appropriate for the program. 
6. Avoid using SELECT * and Select only the required fields from the table. 
7. Avoid using ORDER BY in SELECT statements if it differs from used index  (instead, sort the resulting internal table), because this may add additional work to the database system which is unique, while there may be many ABAP servers 
8. Avoid Executing an identical Select (same SELECT, same parameter) multiple times in the program. Buffer in your abap code. Use read table statement for the second select statement. 
9. Avoid using join statements if adequate standard views exist no performance impact 

           

TABLE BUFFER: 

1. Defining a table as buffered (SE11) can help in improving the performance but this has to be used with caution. Buffering of tables leads to data being read from the buffer rather than from table 
2.  Avoid using complex Selects on buffered tables, because SAP may not be able to interpret this request, and may transmit the request to the database. The code inspector tells which commands bypass the buffer 

 

Internal tables 

1. Use HASHED tables where-ever possible, Otherwise SORTED tables. STANDARD tables should be the last choice. 
2. Use assign instead of into in LOOPs for table types with large work areas, if the data is being modified. 
3. When in doubt call transaction SE30 and check your code. 
4. If you must use a STANDARD table and you are using a READ, sort the table appropriately and use the addition BINARY SEARCH to speed up the search.  

 

Miscellaneous 

1. PERFORM: When writing a subroutine, always provide type for all the parameters. This reduces the overhead which is present when system determines on it’s own each type from the formal parameters that are passed. It also makes for more robust programming. 
2. Try to avoid calling same function module two times in your program. Instead of calling the function module two times in same program, call it only once and pass all the values in the function module.  
3. JOINS are recommended over FOR ALL ENTRIES. In some scenarios, we are presented with an internal table. In these situations, we may have no choice but to use FOR ALL ENTRIES. 
4. Clear the work area and refresh the internal table before using them just to avoid any unwanted result. It is a good practice, but make sure that the work area and internal table is not containing any previous data. 
5. Avoid using nested loops. 

 

Following tools can be used to help with performance tuning: 

1. Tcode ST05:  ST05 is the performance trace. It contains the SQL Trace plus RFC, enqueue and buffer trace. Mainly the SQL trace is is used to measure the performance of the select statements of the program. 

 GO to tcode ST05: 

Choose display trace, then the below screen will appear. Then give the Object name for which we want to trace the performance. 

2. Tcode SE30:SE30 is the Runtime Analysis transaction and can be used to measure the application performance.  

Step1: Go to tcode SE30. 

Give the program name and measurement restriction then execute it.  

 

It is recommended that we should create three measurement variants: 

• PERF_BY_CALL (default): nothing selected on the first tab, on the statement tab everything selected but not the ‘kernel-level runtime administration’ and not the ‘Internal tables’ read and change operations; on the third tab set aggregation ‘per call position’ and set the maximum file size to 20.000 KB and the maximum runtime to 3.000 sec. 
• PERF_BY_CALL_ITAB: as above, but on the second tab the internal table read and change operations are switched on. 

• PERF_NO_AGG: as PERF_BY_CALL, but on the third tab the aggregation is ‘none’. 

The measurement restriction has below three tabs: 

Step 2: After the test program has finished, navigate back to the start screen of the ABAP Trace, where you will find the latest trace file. 

Step3 : During evaluation of the trace you will first see the overview screen.

3. Tcode SAT: 

SAT transaction is the replacement of the pretty outdated SE30.Provides same functionality as SE30 plus some additional features. 

Step1: Go to tcode SAT. The screen is similar to SE30 screen. One new tab Evaluate has been added to the screen.

Variants – The Basis of All Measurements 

The variants are the basis of all measurements in SAT. We maintain trace conditions and restrictions in a variant. 

Step2:  Before we start a measurement just press New button in the Settings area on the SAT initial screen to create a new variant. We will see the screen with three tabs, which we already know from the SE30: Duration and type, Statements, Program Components. 

Step3:  If you used Explicit Switching on and Off of Measurement option in your variant to switch on/off the trace only where you really need it, you have to activate the trace after your ABAP program is running. Enter “/ron” (trace on) command in the OK code field in your transaction. Alternatively you can also use the menu path: System -> Utilities -> Runtime Analysis -> Switch On. 

Step4: The old SE30 transaction offered only two main tools, the Hit List and the Call Hierarchy. SAT offers a rich set of new tools to analyze different aspects of a trace: 

4. Tcode ST12: ST12 transaction (part of ST-A/PI software component) is a combination of ST05 and SAT. Very powerful performance analysis tool used primarily by SAP Support. 

 

5. Code Inspector: One of the best tools for static performance analyzing is Code Inspector (SCI). There are many options for finding common mistakes and possible performance bottlenecks. 

 

Conclusion  

• Database fetching statement plays an important role in ABAP performance 
• Need to use some performance tuning tool in order to check the performance of our program.