Scribd
Upload
9 views6 pages

ABAP Performance

Uploaded by

Rodrigo Martín Fernández
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
9 views6 pages

ABAP Performance

Uploaded by

Rodrigo Martín Fernández
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 6

http://web.mit.edu/sapr3/dev/newdevstand.

html

V. PERFORMANCE STANDARDS
General Performance Standards
1. "Dead" code
Avoid leaving "dead" code in the program. Comment out variables that are not
referenced and code that is not executed. To analyze the program, use the
Program Analysis function in SE38 -> Utilities -> Program Analysis.
2. Use logical databases
Choose the most efficient logical data base possible. Study the selection criteria
and which secondary indexes are used for that view. Provide the appropriate
selection criteria to limit the number of data base reads. Force users to provide
selection criteria by evaluating the selection criteria entered on the selection
screen during the AT SELECTION-SCREEN event. Finally, when possible take
advantage of the matchcodes to increase speed.
3. Subroutine usage
For good modularization, the decision of whether or not to execute a subroutine
should be made before the subroutine is called. For example:

This is better:

IF f1 NE 0.
PERFORM sub1.
ENDIF.
FORM sub1.
...
ENDFORM.

Than this:

PERFORM sub1.
FORM sub1.
IF f1 NE 0.
...
ENDIF.
ENDFORM.
4. IF statements
When coding IF tests, nest the testing conditions so that the outer conditions
are those which are most likely to fail. For logical expressions with AND, place
the mostly likely false first and for the OR, place the mostly likely true first.
5. CASE vs. nested IFs
When testing fields "equal to" something, one can use either the nested IF or
the CASE statement. The CASE is better for two reasons. It is easier to read
and after about five nested IFs the performance of the CASE is more efficient.
6. MOVE-ing structures
When records a and b have the exact same structure, it is more efficient to
MOVE a TO b than to MOVE-CORRESPONDING a TO b.
MOVE BSEG TO *BSEG.

is better than

MOVE-CORRESPONDING BSEG TO *BSEG.


7. SELECT and SELECT SINGLE
When using the SELECT statement, study the key and always provide as much
of the left-most part of the key as possible. If the entire key can be qualified,
code a SELECT SINGLE not just a SELECT. If you are only interested in the
first row or there is only one row to be returned, using SELECT SINGLE can
increase performance by up to 3x.
8. Small internal tables vs. complete internal tables
In general it is better to minimize the number of fields declared in an internal
table. While it may be convenient to declare an internal table using the LIKE
command, in most cases, programs will not use all fields in the SAP standard
table. For example:

Instead of this:

data: tvbak like vbak occurs 0 with header line.

Use this:

data: begin of tvbak occurs 0,


vbeln like vbak-vbeln,
...
end of tvbak.
9. Row-level processing of a table
Selecting data into an internal table using an array fetch versus a SELECT-
ENDELECT loop will give at least a 2x performance improvement. After the data
has been put into the internal data, then row-level processing can be done.
For example, use:
select ... from table <..>
into table <itab> (corresponding fields of table itab)
where ...

loop at <itab>
<do the row-level processing here>
endloop.

instead of using:

select ... from table <..>


where ...
<row-level processing>
append <itab>.
endselect.
10. Row-level processing and SELECT SINGLE
Similar to the processing of a SELECT-ENDSELECT loop, when calling multiple
SELECT-SINGLE commands on a non-buffered table (check Data Dictionary ->
Technical Info), you should do the following to improve preformance: Use the
SELECT into <itab> to buffer the necessary rows in an internal table, next sort
the rows by the key fields, then use a READ TABLE WITH KEY ... BINARY
SEARCH in place of the SELECT SINGLE command. Note that this only make
sense when the table you are buffering is not too large (this must be made on a
case by case decision basis).
11. READing single records of internal tables
When reading a single record in an internal table, the READ TABLE WITH KEY is
not a direct READ. Therefore, SORT the table and use READ TABLE WITH KEY
BINARY SEARCH.
12. SORTing internal tables
When SORTing internal tables, specify the fields to SORTed.
SORT ITAB BY FLD1 FLD2.

is more efficient than

SORT ITAB.
13. Number of entries in an internal table
To find out how many entries are in an internal table use DESCRIBE.
DESCRIBE TABLE ITAB LINES CNTLNS.

is more efficient than

LOOP AT ITAB.
CNTLNS = CNTLNS + 1.
ENDLOOP.
14. Length of a field
To find out the length of a field use the string length function.
FLDLEN = STRLEN (FLD).

is more efficient than

IF FLD CP ‘* #’.
ENDIF.
FLDLEN = SY-FDPOS.
15. Performance diagnosis
To diagnose performance problems, it is recommended to use the SAP
transaction SE30, ABAP/4 Runtime Analysis. The utility allows statistical
analysis of transactions and programs.
16. Nested SELECTs versus table views
Since OPEN SQL does not allow table joins, often a nested SELECT loop will be
used to accomplish the same concept. However, the performance of nested
SELECT loops is very poor in comparison to a join. Hence, to improve
performance by a factor of 25x and reduce network load, you should create a
view in the data dictionary then use this view to select data.
17. If nested SELECTs must be used
As mentioned previously, performance can be dramatically improved by using
views instead of nested SELECTs, however, if this is not possible, then the
following example of using an internal table in a nested SELECT can also
improve performance by a factor of 5x:

Use this:

form select_good.
data: tvbak like vbak occurs 0 with header line.
data: tvbap like vbap occurs 0 with header line.

select * from vbak into table tvbak up to 200 rows.


select * from vbap
for all entries in tvbak
where vbeln=tvbak-vbeln.
endselect.
endform.

Instead of this:

form select_bad.
select * from vbak up to 200 rows.
select * from vbap where vbeln = vbak-vbeln.
endselect.
endselect.
endform.
18. SELECT * versus SELECTing individual fields
In general, use a SELECT statement specifying a list of fields instead of a
SELECT * to reduce network traffic and improve performance. For tables with
only a few fields the improvements may be minor, but many SAP tables contain
more than 50 fields when the program needs only a few. In the latter case, the
performace gains can be substantial. For example:

Use:

select vbeln auart vbtyp from table vbak


into (vbak-vbeln, vbak-auart, vbak-vbtyp)
where ...

Instead of using:

select * from vbak where ...


19. Avoid unnecessary statements
There are a few cases where one command is better than two. For example:
Use:

append <tab_wa> to <tab>.

Instead of:

<tab> = <tab_wa>.
append <tab> (modify <tab>).

And also, use:

if not <tab>[] is initial.

Instead of:

describe table <tab> lines <line_counter>.


if <line_counter> > 0.
20. Copying or appending internal tables
Use this:
<tab2>[] = <tab1>[]. (if <tab2> is empty)

Instead of this:

loop at <tab1>.
append <tab1> to <tab2>.
endloop.

However, if <tab2> is not empty and should not be overwritten, then use:

append lines of <tab1> [from index1] [to index2] to <tab2>.

ABAP/4 Tuning Checklist


The general performance standards above outline ways to increase efficiency from
many different perspectives, the following checklist was developed by SAP to quickly
review the most common performance problems. Please note that some of the
information may overlap with the general performance section.
Is the program using SELECT * statements?
Convert them to SELECT column1 column2 or use projection views.
Are CHECK statements for table fields embedded in a SELECT
... ENDSELECT loop?
Incorporate the CHECK statements into the WHERE clause of the SELECT
statement.
Do SELECTS on non-key fields use an appropriate DB index
or is the table buffered?
Create an index for the table in the data dictionary or buffer tables if they are
read only or read mostly.
Is the program using nested SELECTs to retrieve data?
Convert nested SELECTs to database views, DB joins (v4.0), or SELECT xxx FOR
ALL ENTRIES IN ITAB.
Are there SELECTs without WHERE condition against files
that grow constantly (BSEG, MKPF, VBAK)?
Program design is wrong - back to the drawing board.
Are SELECT accesses to master data files buffered (no
duplicate accesses with the same key)?
Buffer accesses to master data files by storing the data in an internal table and
filling the table with the READ TABLE ... BINARY SEARCH method
Is the program using SELECT ... APPEND ITAB ... ENDSELECT
techniques to fill internal tables?
Change the processing to read the data immediately into an internal table
(SELECT VBELN AUART ... INTO TABLE IVBAK ...)
Is the program using SELECT ORDER BY statements?
Data should be read into an internal table first and then sorted unless there is
an appropriate index on the ORDER BY fields
Is the programming doing calculations or summartions that
can be done on the database via SUM, AVG, MIN, or MAX
functions of the SELECT statement?
Use the calculation capabilities of the database via SELECT SUM, ...
Are internal tables processed using the READ TABLE itab
WITH KEY ... BINARY SEARCH technique?
Change table accesses to use BINARY SEARCH method
Is the program inserting, updating, or deleting data in dialog
mode (not via an update function module)?
Make sure that the program issues COMMIT WORK statements when one or
more logical units of work (LUWs) have been processed.

You might also like