ABAP Performance and Best Practices A Bible V1 0

Page 1
ABAP performance and best practices .

- a Bible.
Page 2
WBEI Engagement Overview
Proprietary and confidential Copyright Capgemini 2007 All Rights Reserved
Symbols used :
Symbol Meaning
Very good performance(recommended).
Forbidden (never use).
Not the best method (to be used only when there is no other way).
A prerequisite (must do activity).
Additional information .
Page 3
What is it all about ?
Write a program quickly and save time ?
Write a program accurately which will be more performing in its execution time
and would not break in real time?
Page 4
Goals :
Explore the areas of performance tuning in ABAP .
Write fine tuned new ABAP programs .
Fine tune existing ABAP programs .
Page 5
Performance Areas in ABAP .
General Rules.
Selection on a single table .
Selection on many tables .
Commit and Rollback .
Data Dictionary .
Mass treatment Internal table and data base .
Operations on internal tables .
Special topics .
Tools available to validate source code from performance and standards point of view.
Tools available to measure performance.
Page 6
General rules : Dos of a good programming .
DOS
Maintain standard documentation headers for programs and subprograms (describing author, function,
changes, interface, side-effects)
Document the interfaces of subroutines and functions
Indent the lines of your programs
Modularize your programs
Specify the type of data objects explicitly (if possible)
Use speaking names for variables and fields
Page 7
General rules : Donts of a good programming .
DONTS
Avoid NULL statements (statements without effect)
Avoid deeply nested loops
Avoid unreachable program parts
Avoid side-effects on global variables
Do not use a variable for multiple purposes (e.g. as counter and as string)
Avoid spaghetti code .
Page 8
General rules :
When we use the <SELECT INTO TABLE wt_table> instruction, exchanges between the database
server and the application server are made by packets.
When we use the <SELECT ENDSELECT> instruction, exchanges between the database
server and the application server are one recording by one recording.
Data loading in Internal table
Page 9
General rules :
SELECT SINGLE
SELECT UP TO 1 ROWS
ENDSELECT
SELECT INTO TABLE wt_table
SELECT INTO TABLE wt_table
FOR ALL ENTRIES
SELECT
ENDSELECT.
Logical databases
Nested select
GROUP BY
ORDER BY
[]CORRESPONDING FIELDS OF []
DISTINCT
Page 10
General rules :
Queries are forbidden because programs generated by a Query are not performing
at all. Requests are not optimized, thus execution time is too high.
Queries
Page 11
Selection on a single table :
SELECT *
FROM table
WHERE field1 = xxx.
Treatment.
EXIT.
ENDSELECT.
SELECT *
FROM table
UP TO 1 ROWS
WHERE field1 = xxx.
Treatment.
ENDSELECT.
SELECT SINGLE *
FROM table
WHERE field1 = xxx.
IF sy-subrc = 0.
Treatment.
ENDIF.
Use : field1 is not the
primary key.
Use : field1 is the primary
key or a part of the primary
key.
After many compared tests, it is proven that the <SELECT SINGLE> instruction
seems to be more efficient that <UP TO 1 ROWS> one.
Page 12
When we are on the instruction which follows <ENDSELECT>, we do not know if we have
gone into the <SELECT> instruction or not. This implies that it is always necessary to
test the return code after the <SELECT> instruction.
Except for the particular cases: Use: Selection of a limited number
of fields.
SELECT SINGLE *
FROM table
WHERE field2 = xxx.
SELECT SINGLE field1
INTO table-field1
FROM table
WHERE field2 = xxx.
8 . 0
table the of fields of number
fields selected of number
Page 13
Selection on a single table : The <where> clause .
The order of the fields in the <WHERE> clause has an impact on the execution time of
the request. SAP works with a positioning pointer on the tables. The first field of the
<WHERE> clause permits the pointer to position itself. Then the table is sequentially
read. Therefore the order of the tests in the <WHERE> clause is very important.
When the developer codes an instruction in order to read in the database, he/she must respect
the following rules by ascending priority:
Put the fields in the same order of the existing index (primary or secondary).
Put the fields in the same order of the key .
Runtime chooses the index based on the fields used in <where> clause.
Order of the fields in <where> clause is very important in deciding index.
Page 14
Selection on a single table : Index (to speed up data fetch) .
Primary Fields forming the primary key of the table form primary index.
Every table has a primary index by default.
Created automatically when the table is activated .
As far as possible , primary index should be used .
Secondary Consists of fields from non primary keys.
When the primary index cannot be used , secondary indexes
have to be created explicitely .
When the table is client dependent , the secondary index must
contain MANDT as first field .
Slows related SAP transactions .
No Index Fields in the <where> clause doesnot form fields from any index
.
Page 15
Selection on a single table : <select > statement
SELECT SINGLE *
INTO table
FROM table
WHERE field = xxxx.
SELECT SINGLE *
FROM table
WHERE field = xxxx.
Page 16
Selection on a single table : Data sorting.
Data sorting
Sorting on the database server. Sorting on the application server.
SELECT *
FROM table
WHERE field1 = xxxx
ORDER BY field2.
Treatment.
EXIT.
ENDSELECT.
SELECT *
INTO TABLE wt_table
FROM table
WHERE field1 = xxxx.
IF sy-dbcnt NE 0.
SORT wt_table BY field2.
LOOP AT wt_table.
Treatment.
ENDLOOP.
ENDIF.
Page 17
Selection on a single table : <into> option
Treatment without storing the data into a
table.
SELECT SINGLE *
INTO table
FROM table
IF sy-dbcnt NE 0.
wv_field2 = table-field2.
Treatment.
ENDIF.
SELECT SINGLE field2
INTO wv_field2
FROM table
WHERE field1 = xxxx
IF sy-dbcnt NE 0.
Treatment.
ENDIF.
Page 18
<INTO TABLE> option :
This option permits to stock many records in an internal table.
It is not necessary to carry out a <REFRESH> of the internal table because it is automatically made
by this option. Furthermore, the <APPEND> of the internal table is implicit.
There is no <ENDSELECT> instruction because it is not a loop treatment. The storage of the table
is carried out at one go.
<APPENDING TABLE> option :
This option permits to add further records to an internal specified table.
The <APPEND> instruction is included is the <APPENDING TABLE> instruction. If the internal table
is refreshed (<REFRESH>) just before using the <APPENDING TABLE> instruction, it is the same
as using the <INTO TABLE> instruction. Therefore if the internal table is empty, the <APPENDING
TABLE> instruction must not be used.
There is no <ENDSELECT> instruction because it is not a loop treatment. The updating of the table
is carried out at one go.
Page 19
<[] CORRESPONDING FIELDS OF []> options
If we want to stock the contents of the chosen fields in another field (different of the buffer), it must have the
same structure as the chosen fields.
The <INTO CORRESPONDING FIELDS OF> instruction is equivalent to a <MOVE-CORRESPONDING> one
between the selected columns and the stocking fields.
Indeed, this option is used when there is a difference between the structure consisted of the fields of the
<SELECT> and the target (in the <INTO>). In this case, the SAP process researches one after one the fields
which have the same names and then make the allocation.
But it is better to put the fields of the <SELECT> instruction in the same order of the
structure declaration or the internal table in order to be quicker.
Page 20
Not recommended use of <INTO CORRESPONDING FIELDS OF>
Direct storage into a table or a structure, without using the fields.
SELECT SINGLE *
INTO CORRESPONDING FIELDS OF table
FROM table
WHERE key = xxxx.
SELECT SINGLE *
FROM table
WHERE key = xxx.
DATA: BEGIN OF ws_struct,
field1 LIKE table-field1,
END OF ws_struct.
SELECT SINGLE *
INTO CORRESPONDING FIELDS OF
ws_struct
FROM table
DATA : BEGIN OF ws_struct,
END OF ws_struct.
SELECT SINGLE field1 field2 field3
INTO ws_struct
FROM table
Page 21
Not recommended use of <INTO CORRESPONDING FIELDS OF>
Direct storage into a table or a structure, without using the fields.
DATA : BEGIN OF wt_table OCCURS 0,
END OF wt_table.
SELECT *
wt_table
FROM table
APPEND wt_table.
ENDSELECT.
DATA : BEGIN OF wt_table OCCURS 0,
END OF wt_table.
SELECT field1 field2 field3
INTO TABLE wt_table
FROM table
SELECT *
TABLE wt_table FROM table WHERE field1
= xxxx.
SELECT field1 field2 field3
INTO TABLE wt_table
FROM table WHERE field1 = xxxx.
Page 22
Selection on a single table : <FOR ALL ENTRIES IN>
To use the <FOR ALL ENTRIES IN> option:
The internal table must not be empty.
The recordings must be sorted in order to
delete the duplicates.
The <WHERE> clause must consist of equalities.
If the internal table is empty, the <SELECT> instruction loops on all of the data of the selected
table.
The deletion of the duplicates is compulsory for two reasons:
It enables to accelerate the execution of the <SELECT FOR ALL ENTRIES> instruction since
the volume of the internal table is smaller.
It avoids some dumps of the programs because of a lack of memory in the table2 table (See the
following example)
If we know that the internal table has duplicates, we have to copy the internal table, sort it and
delete its duplicates.
Page 23
Selection on a single table : <For all entries>
- test the number of recordings
- sort the recordings
- delete the duplicates
SELECT *
INTO TABLE wt_table1
FROM table1
WHERE field1 IN s_field1.
SELECT *
FROM table2
FOR ALL ENTRIES IN wt_table1
WHERE field1 = wt_table1-field1
AND field2 = xxxx.
Treatment.
SELECT *
FROM table
WHERE field1 IN s_field1.
IF sy-dbcnt NE 0.
SORT wt_table1 BY field1.
DELETE ADJACENT DUPLICATES FROM
wt_table1
COMPARING field1.
SELECT *
FROM table2
FOR ALL ENTRIES IN wt_table1
WHERE field1 = wt_table1-field1
AND field2 = xxxx.
Treatment.
ENDIF.
Page 24
Selection on many tables : Logical database (LDB)
Advantages :
Directory structure of related tables.
Reusability .
Selection screen .
Performance :
This method is forbidden because in SAP R/3 it is far from being the most performing
method for reading data in the databases.
Page 25
Selection on many tables : Nested select.
SELECT *
FROM table1
WHERE .
Treatment.
SELECT *
FROM table2
WHERE table1-field1 = table2-field1 AND .
Treatment.
ENDSELECT.
Treatment.
Considering the important number of accesses to the database, this method is not
very performing from the point of view of the execution duration. Therefore it is
forbidden to use it.
Page 26
Selection on many tables : Sub-query
A sub-query solicits the database sever. So, it is not recommended.
SELECT * FROM table
INTO TABLE wt_table
WHERE field IN ( SELECT FROM WHERE).
Page 27
Selection on many tables : Joins
Principle :
Instead of carrying out the selections in many tables from the database, the join permits to
carry out dynamically in memory only one access to the different tables. The join can be
assimilated to a view but the difference is that the join is not defined in the dictionary.
SELECT mkpf~mblnr mkpf~mjahr mseg~zeile mseg~
FROM mkpf INNER JOIN mseg ON mseg~mblnr = mkpf~mblnr
AND mseg~mjahr = mkpf~mjahr
WHERE mkpf~ =
AND mseg~ = .
Treatment.
Page 28
Selection on many tables : Joins
Advantage
The developer maintains that he makes only one access because the code can be
interpreted like a <SELECT* FROM table WHERE Treatment ENDSELECT>.
This is a lot quicker than the method of nested SELECT because there are fewer
accesses to the database.
Drawback
The system needs a lot of memory space because it dynamically creates a pseudo table
of pointers in order to optimize the different accesses to different tables of the join.
The performance problem comes from the fact that the code generated by SAP is
interpreted by an internal layer at SAP and not by the database server itself.
The inner join can be only used in the case of a 1 to n relation on the key of type header
data <-> item data.
In the other cases, it is forbidden.
Page 29
Selection on many tables : <For all entries>
* Selection of data at the top
of the table
SELECT * INTO TABLE
wt_mkpf FROM mkpf
WHERE
AND .
IF sy-dbcnt NE 0.
SORT wt_mkpf BY mblnr
mjahr.
* Selection of data from the
table lines
SELECT * INTO TABLE
wt_mseg FROM mseg
FOR ALL ENTRIES IN
wt_mkpf
WHERE mblnr =
wt_mkpf-mblnr
AND mjahr = wt_mkpf-
mjahr
AND lgort = wc_lgort.
IF sy-dbcnt NE 0.
SORT wt_mseg BY mblnr mjahr zeile.
* Treatment of the selected data
LOOP AT wt_mseg.
Treatment.
AT NEWmjahr.
CLEAR wt_mkpf.
READ TABLE wt_mkpf WITH KEY mblnr = wt_mseg-mblnr
mjahr = wt_mseg-mjahr
BINARY SEARCH.
Treatment.
ENDAT.
Treatment.
AT END OF mjahr.
Treatment.
ENDAT.
Treatment.
ENDLOOP.
ENDIF.
ENDIF.
Page 30
<For all entries> : Pros and Cons .
1. It is important to test the number of records returned during the stocking in an internal table
from the first transparent table and to read the second transparent table, only if the internal table
contains at least one record. Indeed, if the test is not done and if the first table is empty, the access
to the second table will provide ALL the records of this table.
2. If there are several identical records, the result given by the clause <for all entries in> will keep
only the first occurrence. To avoid this major inconvenience, it is compulsory to quote the complete
key in the list of fields to be selected.
Advantage :
This reduces the number of accesses to the database not only from the data selection but also
from the data processing in the body of the program.
Drawback :
In some cases we can choose more data than necessary in reality. Furthermore if there are many
tables to stock it will request a large quantity of memory.
Page 31
Selection on many tables : Views
Principle :
A view is a virtual table which does not have a physical existence and which is composed of
columns belonging to one or many tables. During the first call of the view, the system loads all
the data into a memory table corresponding to the view.
Advantage : There are very few accesses to the database for choosing many
records which are in different tables.
Drawback : If we want to optimize all the programs by this method, it should be
necessary to create at least as many views as that of the programs. But it takes a
lot of memory space. Furthermore, if there are many tables in the view, the relation
between them must point on a key or on an index so that the view may be the most
performing.
Many views have been created by SAP. So we must use them in priority (instead of
using a inner join). We must avoid creating new specific views because of the
memory space.
Page 32
Using recommendations :
Type of selection on
many tables
Using
recommendat
ions (1=high,
6=low)
Commentary
For all entries 1 Always use it except in the case of a 1 to n
relation. Test if the table is empty, sort the
table and delete duplicates.
Join 2 Use it when there is a 1 to n relation on the
key.
View 3 Use the views created by SAP.
Avoid creating new specifics views.
Sub-query 4 Not recommended.
Nested select 5 Forbidden.
Logical database 6 Forbidden.
Page 33
Commit and Rollback: Best practices
DELETE FROM y9nav WHERE zznom NE space
OR zzpavillon NE space.
IF sy-subrc NE 0.
ROLLBACK WORK.
EXIT.
ENDIF.
By extension, after each database correction, it is important to keep the database in
a stable statement. To do this, test the return code of the correction instruction to
make a rollback if the sy-subrc is not equal to zero.
It is forbidden to use the <COMMIT> instruction in the case of a program that
updates tables by carrying out many treatments to do it (in User-Exit for example).
It is also forbidden to use the <COMMIT> instruction in loop structure.
Page 34
Data dictionary: Table creation
Summary of the parameters for a specific table
Question Yes No
Delivery class Do we wish to update the table in
production only by transport?
Delivery class C Delivery class
A
Does the modification of the table
need obligatory integration tests?
Table maintenance Must the table be manually
modified?
Is it possible to use the SM30/SM31
transaction to maintain it?
Tick authorized
SM30/SM31 box and
generate the table
maintenance
Specific
program
Data Type Is the table of delivery class C? Data type APPL2 See the
following
question.
Is the table often modified? Data type APPL1 Data type
APPL0
Table category Is the size of the table in production
uncertain?
Choose a category
with a size greater
than those of the
forecast
Key the
corresponding
size category
between 0 and
4.
Page 35
Data dictionary: Table creation
Summary of the parameters for a specific table
Question Yes No
Buffering Is the table often read by transactions?
Is the table rarely modified ?
It is possible to buffer
the table.
It is forbidden to
buffer the table.
Is the table use buffering?
Is the table small?
Is the number of readings high?
Is the number of writings small?
Complete buffering See the following
question.
Is the table large?
Are few different recordings read?
Individual buffering See the following
question.
Is the table always read with the same
beginning of key (language code,
company, analytical perimeter, country
code)?
Generic buffering No buffering
Log data
changes
Is the volume of creations/modifications
is small?
Log Data Changes No Log Data
Changes
Is it important to know who and when a
table has been modified?
Is it important to be able to restitute the
table contents at a given date?
Page 36
Data dictionary: Buffering .
Buffering a table is forbidden in most of the cases. However, in some cases and when a good
optimization is important, we can use it.
The particular case is the following one:
transparent or pool table,
AND access to the table by reading,
AND a lot of queries to the table,
AND access by primary key (or a part of it),
AND few data updating.
Page 37
Mass treatment Deletion .
Internal table : If we want to delete many records from an internal table satisfying a condition, it is
recommended to carry out a large suppression instead of a suppression record by record.
Deletion record by record. Large deletion.
LOOP AT wt_table
WHERE field1 = xxx.
DELETE wt_table.
ENDLOOP.
DELETE FROM wt_table
WHERE field1 = xxx.
Transparent table : The mass deletion is good when we want to delete records from a transparent
table. Instead of erasing the records one by one, it is advised to stock the records for deletion (only
the key fields) in an internal table with the format of the complete key (even <mandt> field) of the
transparent table and afterwards to use the instruction <DELETE table FROM TABLE wt_table>.
Page 38
Mass treatment Deletion
Case 1: The comparison in the <WHERE> clause is made with a constant
Deletion record by record. Mass deletion
SELECT *
FROM table
WHERE field1 = wc_const.
IF sy-subrc = 0.
DELETE table.
ENDIF.
ENDSELECT.
DELETE FROM table
Page 39
Mass treatment Deletion .
Case 2: The comparison in the <WHERE> clause is made with a variable (a field of wt_table)
Deletion record by record. - Storage of the data for deletion in an internal table.
- Deletion of the data of the transparent table thanks to the
internal table.
LOOP AT wt_table.
SELECT *
FROM table
WHERE field1 = wt_table-field1.
IF sy-subrc = 0.
DELETE table.
ENDIF.
ENDSELECT.
ENDLOOP.
DATA: BEGIN OF wt_table OCCURS 0,
mandt LIKE table-mandt,
key1 LIKE table-key1,
key2 LIKE table-key2,
(all the keys of the table)
END OF wt_table.
SORT wt_table_tmp BY field1.
DELETE ADJACENT DUPLICATES FROM wt_table_tmp
COMPARING field1.
SELECT mandt key1 key2 (all the keys)
INTO TABLE wt_table
FROM table
FOR ALL ENTRIES IN wt_table_tmp
WHERE field1 = wt_table_tmp-field1.
IF sy-dbcnt NE 0.
DELETE table FROM TABLE wt_table.
ENDIF.
Page 40
Mass treatment Modification.
Correction record by record Mass correction
LOOP AT wt_table
WHERE field1 = xxx.
wt_table-field2 = aaa.
wt_table-field3 = bbb.
MODIFY wt_table.
ENDLOOP.
CLEAR wt_table.
wt_table-field2 = aaa.
wt_table-field3 = bbb.
MODIFY wt_table
TRANSPORTING field2 field3
WHERE field1 = xxx.
Page 41
Case 1: Use of the <UPDATE> instruction
Modification record by record The <UPDATE> instruction does not
make any check.
SELECT * FROM table
WHERE field3 = wc_const
field1 = wc_const1.
field2 = wc_const2.
MODIFY table.
ENSELECT.
UPDATE table
SET field1 = wc_const1
Field2 = wc_const2
Update Modify
1. Faster.
2. Doesnot make any check before
update .
3. Results into dump if record to be
modified is not found in DB.
1. Slow.
2. Makes a check before update.
3. If record doesnot exist in DB , it will insert a
record .
Page 42
Case 2: Use of the <MODIFY table FROM TABLE wt_table> instruction
Correction record by record
- Storage of the data for correction in an internal
table
- Modifications of the data of the transparent table
thanks to the internal table.
LOOP AT wt_table.
table-field1 = wt_table-field4.
table-field2 = wt_table-field5.
MODIFY table.
ENDLOOP.
LOOP AT wt_table_tmp.
CLEAR wt_table.
wt_table-field1 = wt_table_tmp-field4.
wt_table-field2 = wt_table_tmp-field5.
APPEND wt_table.
ENDLOOP.
DESCRIBE TABLE wt_table.
IF sy-tfill NE 0.
DELETE ADJACENT DUPLICATES FROM
wt_table
COMPARING field1.
MODIFY table FROM TABLE wt_table.
ENDIF.
Page 43
Mass treatment Insert.
Internal tables
LOOP AT wt_table1.
MOVE wt_table1 TO wt_table2.
APPEND wt_table2.
ENDLOOP.
APPEND LINES OF wt_table1
TO wt_table2.
The wt_table1 table must have the same structure as the wt_table2 table.
Performance
This method of appending lines of one table to another is about 3 to 4 times faster than
appending them line by line in a loop.
Page 44
Mass treatment Insert.
Insertion record by record - Storage of the data for insertion in an
internal table
- Insertion of the data into the transparent
table thanks to the internal table.
LOOP treatment.
table-field1 = .
table-field2 = .
INSERT table.
ENDLOOP.
LOOP treatment.
wt_table-field1 = .
wt_table-field2 = .
APPEND wt_table.
ENDLOOP.
SORT wt_table BY field1 .
DELETE ADJACENT DUPLICATES FROM wt_table
COMPARING field1.
INSERT table FROM TABLE wt_table.
Page 45
Operations on internal tables : Read table binary search
To use the <READ TABLE> instruction:
The <BINARY SEARCH> option is compulsory.
The recordings must be sorted before the reading
The sort must be ascending and on the reading key.
This instruction positions itself on the first record in the table that contains the value.
To carry out a direct reading on an internal table, it is better to make a <READ TABLE
wt_table WITH KEY field1 = wv_field1 BINARY SEARCH> because the data research will
be performed by dichotomy and not sequentially.
The ASCENDING sort on the reading key is compulsory. Otherwise, the <READ TABLE
wt_table WITH KEY field1 = wv_field1 BINARY SEARCH> will give a bad result.
Sequential data research.
Forbidden except in the case of a
small internal table
Binary search most prefferred
READ TABLE wt_table
WITH KEY field1 = wv_field1.
READ TABLE wt_table
WITH KEY field1 = wv_field1
BINARY SEARCH.
Page 46
Tips to use the <read table> instruction inside a loop.
<READ TABLE> without
<BINARY SEARCH>
Sort inside a loop.
LOOP AT wt_table1.
(or loop from index, loop where, do)
Treatment.
READ TABLE wt_table2
WITH KEY key.
IF sy-subrc = 0.
Treatment1.
MODIFY wt_table2
INDEX sy-tabix.
ELSE.
Treatment2.
APPEND wt_table2.
ENDIF.
Treatment.
ENDLOOP.
LOOP AT wt_table1.
(or loop from index, loop where, do)
Treatment.
SORT wt_table2 BY key.
WITH KEY key BINARY SEARCH.
IF sy-subrc = 0.
Treatment1.
MODIFY wt_table2
INDEX sy-tabix.
ELSE.
Treatment2.
APPEND wt_table2.
ENDIF.
Treatment.
ENDLOOP.
Page 47
Tips to use the <read table> instruction inside a loop.
A good solution
SORT wt_table2 BY key. (if wt_table2 is not empty)
LOOP AT wt_table1. (or loop from index, loop where, do)
Treatment.
READ TABLE wt_table2 WITH KEY key BINARY SEARCH.
IF sy-subrc = 0.
Treatment1.
MODIFY wt_table2 INDEX sy-tabix.
ELSE.
Treatment2.
INSERT wt_table2 INDEX sy-tabix.
ENDIF.
Treatment.
ENDLOOP.
Page 48
Working with internal tables.
Declaration of an internal table:
During the declaration of the internal table the <OCCURS> perimeter must usually be equal to 0 except
if we know the total number of records of the internal table. If this amount multiplied by the record size is
less than 8000, it is advised to take the value of the total number of records.
Loop : Control break statement.
Control breaks The instructions between <AT > and <ENDAT> are executed only:
AT FIRST In the first pass within the <LOOP>.
AT LAST At the end of the treatment for the last record on the internal table.
AT NEW At the beginning of each control break on the specified zone after the word
<NEW>.
AT END OF At the end of each control break on the specified zone after the word <END
OF>.
Page 49
Loop : Control break statement.
The tables must be sorted before using <AT NEW> and <AT END OF> instructions.
For SAP, the <AT NEW / AT END OF> instructions are executed only if there is at least a
byte which changes its value between the first byte of the buffer in the table and the last
byte of the specified zone in the <AT NEW/AT END OF>.
Page 50
Nested loops.
Basic nested LOOP
LOOP AT wt_table1.
LOOP AT wt_table
Treatment.
ENDLOOP.
ENDLOOP.
Nested LOOP with the WHERE clause
LOOP AT wt_table1.
LOOP AT wt_table2
WHERE field = wt_table1-field.
Treatment.
ENDLOOP.
ENDLOOP.
Page 51
Nested LOOP FROM index with a key-field (Parallel cursor).
Nested LOOP FROM index with one key field
Principle : Donot read the entire second itab .
Remember the last position read .
DATA: BEGIN OF wt_table1 OCCURS 0,
field1 LIKE wt_table1_key,
field4 LIKE table4-field4,
END OF wt_table1.
field1 LIKE wt_table1_key,
END OF wt_table2.
wv_index = 1.
LOOP AT wt_table1.
Treatment.
LOOP AT wt_table2 FROM wv_index.
IF wt_table2-field1 > wt_table1-field1.
wv_index = sy-tabix.
EXIT.
ELSE IF wt_table2-field1 = wt_table1-field1.
Treatment.
ENDIF.
ENDLOOP.
Treatment.
ENDLOOP.
Must condition : Sort on
itab1 and itab2 should be on
same fields .
Page 52
Nested LOOP FROM index with several key-fields(Parallel cursor). Use1 : ws_struct1 and ws_struct2 form the key for search
and there are unique entries with this combination in itab2.
Nested LOOP FROM index with several key fields .
Principle : Donot read the entire second itab . Remember the last position read . Must
condition : Sort on itab1 and itab2 should be on same fields .
DATA: BEGIN OF wt_table1,
field1 LIKE ,
field2 LIKE ,
field3 LIKE ,
field4 LIKE ,
field5 LIKE ,
field6 LIKE ,
END OF wt_table1.
DATA: BEGIN OF wt_table2,
field1 LIKE ,
field2 LIKE ,
field3 LIKE ,
field4 LIKE ,
field5 LIKE ,
field6 LIKE ,
END OF wt_table2.
SORT wt_table1 BY field2 field4 field6.
SORT wt_table2 BY field2 field4 field6.
wv_index = 1.
LOOP AT wt_table1.
ws_struct1-field1 = field2.
IF ws_struct1 = ws_struct2.
Treatment.
ELSEIF ws_struct2 > ws_struct1.
wv_index = sy-tabix.
Exit.
ENDIF.
ENDLOOP.
ENDLOOP.
DATA: BEGIN OF ws_struct1,
field1 LIKE wt_table1-field2,
END OF ws_struct1.
DATA: BEGIN OF ws_struct2,
END OF ws_struct2.
Page 53
Nested LOOP FROM index with several key fields.
Use2 : Refering to last slide , ws_struct1 (and ws_struct2) must be the key of the table. But, if several records can
have the same value for the field of the FROM clause, we must write:
Nested LOOP FROM index with several key fields.
Must condition : Sort on itab1 and itab2 should be on same fields .
DATA: BEGIN OF wt_table1_key,
END OF wt_table1_key.
DATA: BEGIN OF wt_table1
OCCURS 0,
tab1_key LIKE wt_table1_key,
END OF wt_table1.
DATA: BEGIN OF wt_table2
OCCURS 0,
tab1_key LIKE wt_table1_key,
END OF wt_table2.
SORT wt_table1 BY tab1_key.
SORT wt_table2 BY tab1_key.
wv_index = 1.
LOOP AT wt_table1.
Treatment.
IF wt_table2-tab1_key = wt_table1-tab1_key.
Treatment.
ELSEIF wt_table2-tab1_key > wt_table1-tab1_key.
wv_index_tmp = sy-tabix.
EXIT.
ENDIF.
ENDLOOP.
AT END OF tab1_key.
wv_index = wv_index_tmp.
ENDAT.
Treatment.
ENDLOOP.
The index is here memorized in a
temporary variable. The variable
index is only updated when all the
records having the same value for
the field tab1-tab1_key have been
processed.
Page 54
Nested LOOP with READ TABLE BINARY SEARCH:
Nested LOOP FROM
READ TABLE BINARY SEARCH . Use: wt_table1 is not sorted by field1.
SORT wt_table2 BY field.
LOOP AT wt_table1.
Treatment.
WITH KEY field = wt_table1-field1
BINARY SEARCH TRANSPORTING NO FIELDS.
IF sy-subrc = 0.
LOOP AT wt_table2 FROM sy-tabix.
IF wt_table2-field = wt_table1-field1.
Treatment.
ELSE.
EXIT.
ENDIF.
ENDLOOP.
ENDIF.
Treatment.
ENDLOOP.
Page 55
Nested LOOP with a table of <sorted> Type (only up from 4.0 Release)
This method is similar to the previous one. The wt_table2 table being defined as sorted by field1 and field2
fields, the <LOOP WHERE> instruction is optimized in the same way as the <READ BINARY SEARCH>
method. In this case, the coding is easier to read and SAP generates an error if the table is not correctly
sorted.
Performance Deletions and modifications on a table of type <SORTED> are good in term of
performance (as a <READ TABLE BINARY SEARCH>).
But, insertions are very costly because the new records must be correctly positioned so
that the table remains sorted.
So it is not recommended to use this type of table. It is better to use a standard table
with a <READ TABLE BINARY SEARCH> statement for example.
It is necessary to use the instruction <INSERT TABLE wt_table2> to keep the table
sorted and not to have a duplicate key. Append table can lead to short dump.
Page 56
LOOP AT wt_table ASSIGNING <fs> (only up from 4.6 Release)
Up from the 4.6 release it is possible to use the <LOOP AT itab ASSIGNING <fs> instruction. In this
case, the field symbol directly points to the line of the table. It is therefore possible to directly modify a
record without copying it in the header line and update it afterwards.
Up from the 4.6 release.
END OF wt_table1.
FIELD-SYMBOLS: <fs_tab1> LIKE wt_table1.
LOOP AT wt_table1 ASSIGNING <fs_tab1>.
<fs_tab1>-field1 = value1.
<fs_tab1>-field2 = value2.
Treatment.
ENDLOOP.
This instruction is more costly than a classical
<LOOP MODIFY ENDLOOP> because it
requires a time to maintain the table. This solution
is good to use only if lots of data must be updated
in the table.
The READ instruction has a similar coding: READ
TABLE wt_table ASSIGNING <fs>.
Page 57
Comparative study of performance :
Type of loop Performance
(1=high,
7=low)
Commentary
Nested LOOP FROM index
with one key field
1 The execution time is proportional to the
number of records processed. Use: one
field composes the common key of the
tables.
Nested LOOP with several
key fields
2 Use: several fields compose the common
key of the two tables.
Nested LOOP with READ
TABLE BINARY SEARCH
3 Use: A table cannot be sorted.
LOOP AT NEW READ
TABLE BINARY SEARCH
4 Use: no common fields to sort the tables.
Nested LOOP WHERE with
SORTED TABLE
5 The table is defined as a sorted table. Not
recommended.
Nested LOOP WHERE 6 The execution time is exponential to the
number of records processed. Forbidden.
Basic Nested LOOP 7 Forbidden.
Page 58
Form/ Perform:
The use of <FORM> enables to organize the program to make it more readable, easier to maintain,
with appropriate names easier to understand. The <FORM> instruction permits to add on parameters
during the function call. A parameter is a variable. Therefore the conversion is important. That is why, if
a <FORM> is used and has parameters, it is advised to standardize the different parameters as often
as possible in order to avoid the conversions that are very costly in time for the SAP processor. The
<ANY> type is not a real type.
DATA: wv_var TYPE i.
LOOP AT wt_table.
PERFORM add1 USING wv_var.
ENDLOOP.
FORM add1 USING param.
ADD 1 TO param.
Treatment.
ENDFORM.
DATA: wv_var TYPE i.
LOOP AT wt_table.
PERFORM add1 USING wv_var.
ENDLOOP.
FORM add1 USING param TYPE i.
ADD 1 TO param.
Treatment.
ENDFORM.
Page 59
Exception in function modules:
Mechanism to handle error situations and discontinue further processing.
-> Define sufficient exceptions in function modules and raise them as needed.
-> In the calling program handle all the exceptions .
->If no exceptions are available in function module , still handle the others exception .
->Exceptions when raised , if not handled in calling program result in short dump .
Page 60
Special topics:
1. Hashed tables.
2. Buffering.
3. Indexing.
4. PERFORM.
5. Parallel processing.
6. Aggregate functions.
Page 61
Hashed tables:
Principle :
The access to a hashed table is only made by a unique key thanks to a hashed algorithm.
Advantage :
The time required to read a hashed table is independent of the number of read records. Therefore
hashed tables are very useful for voluminous tables which are often accessed for reading.
Sorting a hashed table is impossible.
The key must be complete when we do a research.
The reading of a hashed table is carried out by the <READ TABLE wt_table WITH
TABLE KEY>.
A hashed table is quick in reading; otherwise there is a not lot of uses.
It is impossible to read/ insert/ modify a record in a hashed table by using an index.
Example DATA wt_table TYPE HASHED TABLE OF ws_struct
WITH UNIQUE KEY key
[INITIAL SIZE n] [WITH HEADER LINE]
The cost of a <SELECT INTO TABLE> is the same with a standard internal table or a
hashed table. But the time for reading a hashed table is less than or equal to the time
required for a standard table.
Page 62
Buffering :
Buffering : Buffering a table is forbidden in most of the cases. However, in some cases and when a
good optimization is important, we can use it. The particular case is the following one:
pool table,
AND access to the table by reading,
AND a lot of queries to the table,
AND access by primary key (or a part of it),
AND few data updating.
-> Usually customizing tables are buffered. Transparent tables are prone to frequent changes and
master data tables are huge in size to be buffered.
-> Should not be buffered if secondary index exists on the table.
-> Table should not appear in a view if buffering is allowed.
Page 63
Indexing & Perform:
Indexing : In most of the cases, the creation of an index is not recommended because we must
be very careful. An index can be created when there is no more solution. Each creation must be
studied individually.
PERFORM : The use of <PERFORM> is very important for the program structure. But it is costly.
Therefore, if there are big performance problems, it is advised to avoid using <PERFORM>. In
general PERFORM increases readability of source code and is good to use.
Page 64
Parallel processing :
Concept Call function STARTING NEW TASK DESTINATION IN GROUP allocates the
processing to a new Dialog task.
So the entire data processing can be split into different dialog tasks .
Messages received back from task could be processed via a subroutine in calling
program.
Advantages Faster processing compared to serial processing as it uses asynchronous processing .
Disadvantages As the processing happens in a dialog work process which has a auto logout time
limitation.
Will cause problem if there is a dependency between the data which is processed in two
different dialog tasks.
Prerequisites FM should be RFC enabled.
The calling program should not change to a new internal session after making an
asynchronous RFC call. That is, you should not use SUBMIT or CALL TRANSACTION
in such a report after using CALL FUNCTION STARTING NEW TASK.
Server must have atleast 3 dialog work processes. Dispatcher queue less than 10%
full, at least one dialog work process free for processing tasks from the parallel job.
Page 65
Parallel processing : Example
data: functioncall1(1) type c,
cstgdetail1 type bapicustomer_kna1.
constants: done(1) type c value 'X'.
start-of-selection.
call function
'BAPI_CUSTOMER_GETDETAIL2'
starting new task 'FUNC1'
destination 'NONE'
performing set_function1_done on
end of task
exporting
customerno = p_kunnr.
*Receive remaining asynchronous replies
wait until functioncall1 = done.
write:/ cstgdetail1.
****************************************************
****
* FORM FUNCTION1_DONE
****************************************************
****
form set_function1_done using taskname.
receive results from function
'BAPI_CUSTOMER_GETDETAIL2'
importing
customergeneraldetail = cstgdetail1.
functioncall1 = done.
endform.
Page 66
Aggregate functions: SUM , AVG , COUNT , MIN , MAX
To be avoided when data records that are worked upon in aggregate functions are big
in number.
Can be used in aggregate functions involving small number of data records .
Advantage Data fetched from database to ABAP layer is less .
Aggregation is done on Database level. So no further treatment is necessary on ABAP
layer. Reduces coding effort .
Disadvantage Reduces performance as aggregation is done at database level.
Page 67
Tools available to validate source code: SLIN
Extended syntax check : Tcode SLIN
Does advanced syntax check and lists out all potential coding errors that can lead to runtime breakage of
program
Page 68
Tools available to validate source code: SLIN
Page 69
Tools available to validate source code: SCII
Code Inspector : Tcode SCII
Code inspector lists potential flaws in the program that can affect the performance of the program. Naming
conventions used for objects can be checked against standards. You can create your own project specific
variants or can use a temporary definition .
Page 70
Tools available to validate source code: SCII
Page 71
Tools available to measure performance :
Run time analysis : SE30 (ABAP V/S Database)
Page 72
Run time analysis : SE30 ( Costly database statements ).
Page 73
SQL trace tool : ST05 .
Page 74
SQL trace tool : ST05
Page 75
Page 76
Page 77
ABAP performance and best practices .
- The End.

ABAP Performance and Best Practices A Bible V1 0

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ABAP Performance and Best Practices A Bible V1 0

Uploaded by

Copyright:

Available Formats

Page 1

ABAP performance and best practices .

You might also like