SAP ABAP Performance Tuning Questions

1.

Table of Contents
1.SQL
Interface......................................................................................................................
3
2. String
manipulation.............................................................................................................
5
3. Internal
Tables.................................................................................................................... 6
4. Internal tables vs. Field
group............................................................................................. 8
5.
Typing..........................................................................................................................
....... 8
6. If,
Case, ............................................................................................................................
.8
7. Field
Conversion.................................................................................................................
9
8.
Modularization...........................................................................................................
......... 9
a)
Subroutines.................................................................................................................
.9
b) Function
Modules...................................................................................................... 10
9.
Tools.............................................................................................................................
.... 10
a) Static Analysis (Extended program
check).............................................................. 10
b) Dynamic
Analysis...................................................................................................... 10
c) Database

Access...................................................................................................... 10
10. Getting the data / Data table
identification.................................................................... 11
a) F1-F9 / Technical
info............................................................................................... 11
b) Runtime
analysis....................................................................................................... 11
c)
Debug........................................................................................................................
12
d)
SE38..........................................................................................................................
12
e) Sql
trace.................................................................................................................... 12
f) Logical
database........................................................................................................ 12
g) Function
modules...................................................................................................... 12
11. List of important
tables................................................................................................... 13
12. List of function
modules................................................................................................. 14
13. Formulas for pricing in MM, SD, and
FI......................................................................... 14
1.SQL Interface
11 Select ... Where vs. Select + Check
Always specify your conditions in where clause rather than first selecting all
the records and then using the check syntax.
11
Select with index support
Try and access a table using all its indexes. Consider creating a secondary
index for a table (transparent only) which is frequently accessed for read-only
operations. If there is no index a full table scan is carried out while reading.
The secondary index puts an extra load onto the system whenever the data is
changed or new records are created, as the index is also a table and has to be
updated. Hence, create a secondary index only if must.
11
Select single vs. Select-Endselect

If you are interested in just one database record than use select single rather
than select.where
11
Select ... Into Table t
Selecting into table is much faster than selectappending the table .
11
Select aggregates
If you want to find the maximum, minimum, average and sum from the table,
use SQL aggregrate functions.
11
Select-Endselect vs. Array-Sele
If you want to process your data only once while selecting, use select into table
and loopendloop rather than selectendselect.
11
Select with view
To process a join use a view compared to a
nested select statement.
11
Select with select list
Use a select list (fields to be selected) or a view compared to select * if you only
want to process a few fields.
11
Select with buffer support
For all frequently used read-only tables, try to use SAP buffering. The table
access is automatically buffered unless the following syntax is used:
11
11
11
11
11

Select distinct
Select single for update or
Select singlebypassing buffer
Select..aggregate functions
Using Native SQL

Select count v/s select single *

For checking whether a database record exists, use select single instead
of select count.

11

11

Array Insert VS Single-row Insert

Whenever possible use array operations instead of single row.

e.g.Array insert
INSERT CUSTOMERS FROM TABLE TAB.
Single insert
Loop at tab.
INSERT INTO CUSTOMERS VALUES TAB.
Endloop.
Column Update
Whenever possible use column updates compared to single-row updates.
e.g
UPDATE SFLIGHT SET SEATSOCC = SEATSOCC - 1.
instead of
SELECT * FROM SFLIGHT.
SFLIGHT-SEATSOCC = SFLIGHT-SEATSOCC 1.
UPDATE SFLIGHT.
ENDSELECT.
11
Select single * for update v/s Enqueue
Avoid locking database records with statement select..update. A better
solution is to use enqueue.
11

Accessing cluster/pool tables

When accessing cluster/pool tables ensure that access is ALWAYS by primary
key. The arrangement of data in the pooled tables is such that all the non-key
data is stored as a single field. And a select based on the non-key field is very
slow.

11

Select header data first

Whenever accessing the item details, first get all the header data and then
access the details table giving as many keys as possible using the header data.
This is useful in most case like BKPF-BSEG, VBRK-VBRP, LIKP-LIPS, etc.
Instead of directly accessing the details table, and accessing via the header
table increases the performance. Help of logical database (SE36) hierarchical
structure can be used to determine which is the header table. A table higher
up in the hierarchy should be accessed before a lower one.

11

2. String
manipulation

Special operators in IF (CA, ...)

Use the special string operators CA, CO, CS, Concatenate, Split instead of
programming the logic yourself as the standard functionality is optimized.
11
Deleting leading spaces
If you want to delete the leading spaces in a string use the ABAP
statement shift.left deleting leading. Other logic like using sy-fdpos is not
that fast.
11
String length
Use the strlen() function to restrict the DO loop passes.
11
Initializing strings
Use clear f with val whenever you want to initialize a field with a value
different from the fields type specific initial value.
11

3. Internal
Tables
Building condensed tables
If the amount of data is small, the READ/INSERT approach isnt bad, but for
large amounts of data(> 1000), the collect string is much faster but do not use
collect with any other table filling statements like append insert as collect
cannot use its hash algorithm.
11
Building tables without duplicates
Use Delete adjacent duplicate entries after sorting for large amount of data.
11
Linear vs. binary search
Binary search for an internal table is much faster than just Read.
11
Different forms of key access
If possible, specify the key fields for read access explicitly. Otherwise the key
fields have to be computed dynamically by the run time system.
11

Secondary indices
If you want to access an internal table with different keys repeatedly use your
own secondary indicies. With a secondary index, you can replace a linear
search with a binary search plus an index access.
e.g.
READ TABLE TAB_INDEX WITH KEY DATE = SY-DATUM BINARY
SEARCH.
IF SY-SUBRC = 0.
READ TABLE TAB INDEX TAB_INDEX-INDX.
ENDIF.
Instead of
READ TABLE TAB WITH KEY DATE = SY-DATUM.
IF SY-SUBRC = 0.
" ...
ENDIF.
11
Key access to multiple lines
Loop.where is faster than loop/check because loopwhere evaluates the
specified condition internally.
11

Using explicit work areas

Avoid unnecessary moves by using the explicit work area operations. Append
wa to tab.
11
Copying internal tables
To copy the entire contents of one table into another, use taba() = tabb()
instead of append tabb.
11

Comparing internal tables

Internal tables can be compared in a much faster way by if taba() = tabb().

11

Sorting internal tables

The more restrictively you specify the sort key, the faster the program will
run. i.e. sort tab by k.
11
Nested loops
Use the parallel cursor approach for joining or nesting two internal tables.
e.g
I2 = 1.
LOOP AT TAB1.
LOOP AT TAB2 FROM I2.
11

IF TAB2-K <> TAB1-K.

I2 = SY-TABIX.
EXIT.
ENDIF.
ENDLOOP.
ENDLOOP.
Instead of
LOOP AT TAB!.
LOOP AT TAB2 WHERE K = TAB1-K.
ENDLOOP.
ENDLOOP.
11
Modifying selected components
With the modify variant, Modify itabtransporting f1 f2 accelerates the task
of updating the internal table.
11
Modifying a set of lines
For updating a set of lines use Modify itabtransporting f1
f2 with where.clause.

Appending a table
With the append variant append lines of tab1 to tab2 the task of appending
can be transferred to the kernel which is faster.
11
Inserting a table
With the insert variant insert lines of tab1 into tab2 index idx the task of
inserting can be transferred to the kernel which is faster.
11
Deleting a sequence of lines
With the delete variant delete tab1 from idx1 to idx2 the task of deleting can
be transferred to the kernel which is faster.
11
Deleting a set of lines
Use delete where to delete a set of
lines.
11

4. Internal tables vs. Field group

When there is large amount of data, go for the field group. When there is a
requirement of sorting the extracted data, as the number of records increase,
the internal table sorting becomes slower. When there is a case of sorting large
amount of data, always use field group.

5.
Typing
Typed vs. untyped Parameters/field symbols
If you specify the type of formal parameters/field symbols in your source code,
ABAP can optimize your code more thoroughly. In addition the risk of using
the wrong sequence of parameters in a perform statement is much less.

11

6. If,
Case, ...
.
If vs. Case
CASE statements are clearer and a little faster than IF-constructions.
11
While vs. Do
While is easier to understand and faster to execute.
11

Case vs. Perform i Of ...

A very fast way to call a certain routine using a given index is the perform I of
statement. e.g
(I1 = 5 in this test)
PERFORM I1 OF

11

PV1
.
.
PV5.
Instead of
CASE I1.

WHEN 1. PERFORM PV1.

.
.
.
WHEN 5. PERFORM PV5.
ENDCASE.

7. Field
Conversion
Field Types I and P
Use fields of type I for typical integral variables like indices.

11

Literals Type C and Type I

Use numeric literals when you are dealing with type-I variables like sy-subrc
instead of character strings.

11

Constants Type F
Use properly typed constants instead of literals e.g.
CONSTANTS: PI TYPE F VALUE '3.1415926535897932'.
Instead of
DATA: FLOAT TYPE F.
FLOAT = '3.1415926535897932'.Arithmetic
11
Mixed Types
Dont mix types unless absolutely necessary.
11

ABAP PERFORMANCE ISSUES.

ABAP/4 Optimization

Use the GET RUN TIME command to help evaluate performance. It's hard to
know whether that optimization technique REALLY helps unless you test it out.
Using this tool can help you know what is effective, under what kinds of conditions.
The GET RUN TIME has problems under multiple CPUs, so you should use it to
test small pieces of your program, rather than the whole program.


Avoid 'SELECT *', especially in tables that have a lot of fields. Use SELECT A
B C INTO instead, so that fields are only read if they are used. This can make a very
big difference.

Field-groups can be useful for multi-level sorting and displaying. However,

they write their data to the system's paging space, rather than to memory (internal
tables use memory). For this reason, field-groups are only appropriate for
processing large lists (e.g. over 50,000 records). If you have large lists, you should
work with the systems administrator to decide the maximum amount of RAM your
program should use, and from that, calculate how much space your lists will use.
Then you can decide whether to write the data to memory or swap space. See the
Fieldgroups ABAP example.

Use as many table keys as possible in the WHERE part of your select
statements.

Whenever possible, design the program to access a relatively constant number

of records (for instance, if you only access the transactions for one month, then there
probably will be a reasonable range, like 1200-1800, for the number of transactions
inputted within that month). Then use a SELECT A B C INTO TABLE ITAB
statement.

Get a good idea of how many records you will be accessing. Log into your
productive system, and use SE80 -> Dictionary Objects (press Edit), enter the table
name you want to see, and press Display. Go To Utilities -> Table Contents to query
the table contents and see the number of records. This is extremely useful in
optimizing a program's memory allocation.

Try to make the user interface such that the program gradually unfolds more
information to the user, rather than giving a huge list of information all at once to
the user.

Declare your internal tables using OCCURS NUM_RECS, where NUM_RECS

is the number of records you expect to be accessing. If the number of records
exceeds NUM_RECS, the data will be kept in swap space (not memory).

Use SELECT A B C INTO TABLE ITAB whenever possible. This will read all
of the records into the itab in one operation, rather than repeated operations that
result from a SELECT A B C INTO ITAB... ENDSELECT statement. Make sure
that ITAB is declared with OCCURS NUM_RECS, where NUM_RECS is the
number of records you expect to access.


Many tables contain totals fields (such as monthly expense totals). Use these
avoid wasting resources by calculating a total that has already been calculated and
stored.

Program Analysis Utility

To determine the usage of variables and subroutines within a program, you can use
the ABAP utility called Program Analysis included in transaction SE38. To do so,
execute transaction SE38, enter your program name, then use the path Utilities ->
Program Analysis
ABAP PERFORMANCE IMPROVEMENTS VIA DATA DICTIONARY

INDEX CREATION SUGGESTIONS RELATED TO DATABASE

PERFORMANCE

The columns at the beginning of an index are the most common. The most
common columns are those where reports are selecting columns with no ranges the where clause for these columns is an equal to expression. Rearrange columns
of an index to match the selection criteria. For example, if a select statement is
written to include columns 1 and 2 with equal to expressions in the where clause
and column 3 and 4 are selected with value ranges, then the index should be created
with columns in the sequence of 1,2,3,4.

Columns towards the end of the index are either infrequently used in selects
or are part of reporting selects that involve ranges of values.

TABLE TYPE SUGGESTIONS RELATED TO DATABASE

PERFORMANCE

Use VIEW tables to effectively join and denormalize related tables that are
taking large amounts of time to select for reporting. For example, at times where
highly accessed tables normalize description text into one table and the header data
into another table, it may make sense to create a view table that joins the relevant
fields of the two associated with a poor performing ABAP.

For POOL tables that contain large amounts of data and are highly accessed,
convert the pooled table into a transparent table and add an index. POOLED tables
are supposed to be collections of smaller tables that are quickly accessed from the
database or are completely buffered in memory. Pooled tables containing more than
a few hundred rows and are accessed many times in a report or transaction are
candidates for POOL to TRANSPARENT Conversion. For example, table A053
contains tax jurisdiction condition information and are accessed more than ten times
in the sales order create transaction. If the entire United States tax codes are loaded

into these condition tables, the time to save a sales order increases to unacceptable
levels. Converting the tax condition table to transparent and creating an index based
upon the key fields, decreases processing time from minutes to seconds.

Do not allow the use of LIKE in an SAP SQL statement accessing a large
table.

Use internal tables in ABAPs to preselect values once and store values in
memory for sorting and searching purposes (this is an assumption stated at the
beginning of this discussion).

Avoid logical databases when not processing all row s of a table. In fact, a
logical database is merely a group of nested SAP SQL SELECT statements. In
general, when processing a small number of rows in a larger table is required, the
use of internal tables and NOT using a logical database or nested selects will be
much better for performance.