Professional Documents
Culture Documents
SAP ABAP Performance Tuning Tips & Tricks
SAP ABAP Performance Tuning Tips & Tricks
In this world of SAP programming, ABAP is the universal language. In most of the projects, the focus is
on getting a team of ABAP programmers as soon as possible, handing over the technical specifications to
them and asking them to churn out the ABAP programs within the “given deadlines”.
Often due to this pressure of schedules and deliveries, the main focus of making an efficient program
takes a back seat. An efficient ABAP program is one which delivers the required output to the user in a
finite time as per the complexity of the program, rather than hearing the comment “I put the program to
run, have my lunch and come back to check the results”.
Leaving aside the hyperbole, a performance optimized ABAP program saves the time of the end user,
thus increasing the productivity of the user, and in turn keeping the user and the management happy.
This tutorial focuses on presenting various performance tuning tips and tricks to make the ABAP
programs efficient in doing their work. This tutorial also assumes that the reader is well versed in all the
concepts and syntax of ABAP programming.
NOTE: Performance of a program is also often limited due to hardware restrictions, which is out of the
scope of this article.
Instead of selecting all the data and doing the processing during the selection, it is advisable to restrict the
data to the selection criteria itself, rather than filtering it out using the ABAP code.
Not recommended
Endselect.
Recommended
Endselect.
One more point to be noted here is of the select *. Often this is a lazy coding practice. When a
programmer gives select * even if one or two fields are to be selected, this can significantly slow the
program and put unnecessary load on the entire system. When the application server sends this request
to the database server, and the database server has to pass on the entire structure for each row back to
the application server. This consumes both CPU and networking resources, especially for large
structures.
Thus it is advisable to select only those fields that are needed, so that the database server passes only a
small amount of data back.
Also it is advisable to avoid selecting the data fields into local variables as this also puts unnecessary load
on the server. Instead attempt must be made to select the fields into an internal table.
Use the already provided aggregate functions, instead of finding out the minimum/maximum values using
ABAP code.
Not recommended
Maxnu = 0.
Maxnu = zflight-fligh.
Endselect.
Recommended
Select max( fligh ) from zflight into maxnu where airln = ‘LF’ and cntry = ‘IN’.
The other aggregate functions that can be used are min (to find the minimum value), avg (to find the
average of a Data interval), sum (to add up a data interval) and count (counting the lines in a data
selection).
Many times ABAP programmers deal with base tables and nested selects. Instead it is always advisable
to see whether there is any view provided by SAP on those base tables, so that the data can be filtered
out directly, rather than specially coding for it.
Not recommended
Select single * from zflight where cntry = zcntry-cntry and airln = ‘LF’.
Endselect.
Recommended
Select * from zcnfl where cntry like ‘IN%’ and airln = ‘LF’.
Endselect.
Instead of appending one record at a time into an internal table, it is advisable to select all the records in a
single shot.
Not recommended
Refresh: int_fligh.
Endselect.
Recommended
Refresh: int_fligh.
Use the variations of the modify command to speed up this kind of processing.
Not recommended
Loop at int_fligh.
If int_fligh-flag is initial.
Int_fligh-flag = ‘X’.
Endif.
Modify int_fligh.
Endloop.
Recommended
Int_fligh-flag = ‘X’.
When a programmer uses the read command, the table is sequentially searched. This slows down the
processing. Instead of this, use the binary search addition. The binary search algorithm helps faster
search of a value in an internal table. It is advisable to sort the internal table before doing a binary search.
Binary search repeatedly divides the search interval in half. If the value to be searched is less than the
item in the middle of the interval, the search is narrowed to the lower half; otherwise the search is
narrowed to the upper half.
Not Recommended
Recommended
Instead of using the normal loop-endloop approach for this kind of programming, use the variation of the
append command. Care should be taken that the definition of both the internal tables should be identical.
Not Recommended
Loop at int_fligh1.
Endloop.
Recommended
Append lines of int_fligh1 to int_fligh2.
Use of buffered tables is recommended to improve the performance considerably. The buffer is bypassed
while using the following statements
1. Select distinct
2. Select … for update
3. Order by, group by, having clause
4. Joins
Use the Bypass buffer addition to the select clause in order to explicitly bypass the buffer while selecting
the data.
Outer join can be created using this addition to the where clause in a select statement. It speeds up the
performance tremendously, but the cons of using this variation are listed below
1. Duplicates are automatically removed from the resulting data set. Hence care should be taken
that the unique key of the detail line items should be given in the select statement.
2. If the table on which the For All Entries IN clause is based is empty, all rows are selected into the
destination table. Hence it is advisable to check before-hand that the first table is not empty.
3. If the table on which the For All Entries IN clause is based is very large, the performance will go
down instead of improving. Hence attempt should be made to keep the table size to a moderate
level.
Not Recommended
Loop at int_cntry.
Append int_fligh.
Endloop.
Recommended
When a base table has multiple indices, the where clause should be in the order of the index, either a
primary or a secondary index.
To choose an index, the optimizer checks the field names specified in the where clause and then uses an
index that has the same order of the fields. One more tip is that if a table begins with MANDT, while an
index does not, there is a high possibility that the optimizer might not use that index.
In certain scenarios, it is advisable to check whether a new index can speed up the performance of a
program. This will come handy in programs that access data from the finance tables.
Instead of using the move-corresponding clause it is advisable to use the move statement instead.
Attempt should be made to move entire internal table headers in a single shot, rather than moving the
fields one by one.
When multiple SAP tables are logically joined, it is always advisable to use inner join to read the data
from them. This certainly reduces the load on the network.
Let us take an example of 2 tables, zairln and zflight. The table zairln has the field airln, which is the
airline code and the field lnnam, which is the name of the airline. The table zflight has the field airln, the
airline code and other fields which hold the details of the flights that an airline operates.
Since these 2 tables a re logically joined by the airln field, it is advisable to use the inner join.
In order to restrict the data as per the selection criteria, a where clause can be added to the above inner
join.
The order by clause is executed on the database server, while the sort statement is executed on the
application server. Thus instead of giving the order by in the select clause statement, it is better to collect
the records in an internal table and then use the sort command to sort the resulting data set.
Following are the different tools provided by SAP for performance analysis of an ABAP object
The trace list has many lines that are not related to the SELECT statement in the ABAP program. This is
because the execution of any ABAP program requires additional administrative SQL calls. To restrict the
list output, use the filter introducing the trace list.
The trace list contains different SQL statements simultaneously related to the one SELECT
statement in the ABAP program. This is because the R/3 Database Interface - a sophisticated
component of the R/3 Application Server - maps every Open SQL statement to one or a series of
physical database calls and brings it to execution. This mapping, crucial to R/3s performance,
depends on the particular call and database system. For example, the SELECT-ENDSELECT
loop on the SPFLI table in our test program is mapped to a sequence PREPARE-OPEN-FETCH
of physical calls in an Oracle environment.
The WHERE clause in the trace list's SQL statement is different from the WHERE clause in the ABAP
statement. This is because in an R/3 system, a client is a self-contained unit with separate master records
and its own set of table data (in commercial, organizational, and technical terms). With ABAP, every Open
SQL statement automatically executes within the correct client environment. For this reason, a condition
with the actual client code is added to every WHERE clause if a client field is a component of the
searched table.
To see a statement's execution plan, just position the cursor on the PREPARE statement and
choose Explain SQL. A detailed explanation of the execution plan depends on the database
system in use.