Optimizing ABAP Performance
Optimizing ABAP Performance
Optimizing ABAP Performance
performance
May 2020
Saleem Javed
1. Introduction to optimization
2. Optimizing ABAP code (Do’s and Don’t’s)
3. Performance analysis tools
4. ATC integration and enforcement
2 06/08/2024 © itelligence
What is Performance Optimization?
Performance Optimization is the improvement of system performance typically a
Computer Application.
Typically involves the following steps:
1. Assess problems.
3. Identify the part of the system that is critical for improving the performance.
Open SQL
5 06/08/2024 © itelligence
CDS AMDP capabilities
6 06/08/2024 © itelligence
Optimize ABAP Code
DATABASE :
Look for availability of index based on the mandatory fields available on your selection
screen. Look for possibility of using Primary index if not use secondary Very important !!
Use WHERE clause in your SELECT statement to restrict the volume of data
retrieved. Design the where clause based on index identified in step -1Very important !!
Use INNER (or OUTER under some circumstances) JOIN in your SELECT statement to
retrieve the matching records at one shot.
Avoid using nested SELECT statement and SELECT within LOOPs.
For all entries and Joins can be used instead of the above.
Use FOR ALL ENTRIES when the internal table is already there or at the end of some
processing.
Avoid using INTO CORRESPONDING FIELDS OF TABLE during buffered access. Otherwise
use the most appropriate for the program.
Avoid using SELECT * and Select only the required fields from the table.
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.
INDEX: Index speeds up the performance but at the same time adds two overheads
namely; memory and insert/append performance.
Creation of Index for improving performance should not be taken without thought. When
INDEX is created, memory is used for storing the index and index sizes can be quite big
on large transaction tables!
When inserting new entry in the table, all the index's are updated. More index more time.
More the amount of data, bigger the indices, larger the time for updating all the indices
Avoid Executing an identical Select (same SELECT, same parameter) multiple times in
the program.
Avoid using join statements if adequate standard views exist No impact on the
performance.
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. Buffer
sync with table happens periodically.
Using table buffering for Transaction table is not recommended as there are chances that
the data gets changed for a particular selection criteria, therefore application tables are
usually not suited for table buffering.
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.
Use HASHED tables where-ever possible. Otherwise SORTED tables. STANDARD tables
should be the last choice.
Use assign instead of into in LOOPs for table types with large work areas, if the data is
being modified.
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:
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.
SELECT SINGLE and SELECT UP TO n ROWS return the first matching row/rows for the
given condition. It may not be unique, if there are more matching rows for the given
condition.
Select single can be used if we have a full key else select … Up to 1 rows can be used with
a where clause.
Which is the better - JOINS or SELECT... FOR ALL ENTRIES...?
In most scenarios INNER JOIN performs better than FOR ALL ENTRIES, and should be
used first. Only if there are performance issues FOR ALL ENTRIES should be considered.
Check whether the internal table used for “For all entries” is initial or not, use it only if it
is not initial.
Measure the performance before and after making the changes for further validations.
At times, while trying to improve the performance we tend to break the existing
functionality, be vigilant when doing changes to the existing code.
13 06/08/2024 © itelligence
Check variants for ABAP performance
14 06/08/2024 © itelligence
Performance Optimization - Tools
ST05 is the performance trace. It contains the SQL Trace plus RFC, enqueue and buffer
trace. Mainly the SQL trace is used to measure the performance of the select statements
of the program.
SE30 is the Runtime Analysis transaction and can be used to measure the application
performance.
SAT transaction is the replacement of the outdated SE30. Provides same functionality as
SE30 plus some additional features.
ST12 transaction (part of ST-A/PI software component) is a combination of ST05 and SAT.
It is a powerful performance analysis tool used primarily by SAP Support.
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.
ATC is ABAP's new integrated, standard tool for quality checking. ATC is available from
EhP2 for SAP NetWeaver 7.0 with support package stack 12.
16 06/08/2024 © itelligence
Questions …..?