Performance Tuning of ABAP report program – PART 2
1. Explicit Work Areas vs. Header Lines
Using explicit work areas is more efficient because
header lines are outdated and introduce ambiguity. Avoid header lines for clear
and optimized code.
Example:
abap
DATA: wa_customer
TYPE kna1,
it_customers TYPE TABLE OF kna1.
Inefficient (Using header line):
SELECT FROM kna1
INTO kna1 WHERE land1 = 'DE'.
APPEND kna1 TO
it_customers.
Optimized (Using
explicit work area):
SELECT FROM kna1 INTO wa_customer WHERE land1 = 'DE'.
APPEND wa_customer
TO it_customers.
Explanation: Explicit work areas eliminate the
performance overhead caused by managing header lines.
2. Binary Search
vs. Linear Search
A binary search is much faster than a linear search,
especially for large tables. Always ensure the table is sorted before using
binary search.
Example:
abap
SORT it_customers BY kunnr.
Binary Search:
READ TABLE it_customers WITH KEY kunnr = '000100' BINARY SEARCH.
Explanation: Binary search divides the search space by
half each time, making it far more efficient than linear search.
3. Dynamic Key
Access vs. Static Key Access
Static key access is faster because the runtime doesn't
need to evaluate the key dynamically.
Example:
abap
Dynamic Key Access
(Slower):
READ TABLE
it_customers WITH KEY (lv_field) = lv_value.
Static Key Access
(Faster):
READ TABLE
it_customers WITH KEY kunnr = lv_kunnr.
Explanation: In the dynamic key case, the field name and
value are evaluated at runtime, which is slower than static key access.
4. Binary Search
Using Secondary Index
Using binary search with a secondary index is efficient
for read operations, especially when the table is large.
Example:
abap
Assume that kunnr
has a secondary index:
SORT it_customers BY
kunnr.
READ TABLE
it_customers WITH KEY kunnr = '000200' BINARY SEARCH.
Explanation: A secondary index allows quicker access to
records, reducing search time.
5. LOOP ... WHERE
vs. LOOP ... CHECK
LOOP ... WHERE is faster than using CHECK inside a loop
because the condition is evaluated internally, eliminating unnecessary
iterations.
Example:
abap
Inefficient (Using
CHECK):
LOOP AT it_customers
INTO wa_customer.
CHECK wa_customerkunnr = '000100'.
" Process the entry
ENDLOOP.
Optimized (Using
WHERE clause):
LOOP AT it_customers
INTO wa_customer WHERE kunnr = '000100'.
" Process the entry
ENDLOOP.
Explanation: LOOP ... WHERE stops iterating once the
condition is met, making it more efficient than filtering using CHECK.
6. Using MODIFY
... TRANSPORTING
MODIFY ... TRANSPORTING only updates specified fields,
which reduces the load on memory and CPU.
Example:
abap
Inefficient (Full
update):
MODIFY it_customers
FROM wa_customer.
Optimized
(Selective update):
MODIFY it_customers
FROM wa_customer TRANSPORTING name1 city1.
Explanation: By updating only relevant fields, you avoid
unnecessary data manipulation, improving performance.
7. LOOP ...
ASSIGNING for Faster Table Updates
Using ASSIGNING avoids copying data into the work area
and accelerates updating internal table entries.
Example:
abap
LOOP AT it_customers
ASSIGNING <fs_customer>.
<fs_customer>city1 = 'New York'.
ENDLOOP.
Explanation: The ASSIGNING statement directly references
the internal table row, which is faster than using a work area.
8. Using COLLECT
Instead of READ ... ADD
COLLECT aggregates data directly into an internal table,
improving performance over reading and adding manually.
Example:
abap
DATA: it_sales TYPE
TABLE OF zsales,
wa_sales TYPE zsales.
Inefficient
(Manual aggregation):
READ TABLE it_sales
WITH KEY matnr = '1001' TRANSPORTING NO FIELDS.
IF sysubrc = 0.
ADD 1 TO wa_salesqty.
ELSE.
wa_salesmatnr = '1001'.
wa_salesqty = 1.
APPEND wa_sales TO it_sales.
ENDIF.
Optimized (Using
COLLECT):
wa_salesmatnr =
'1001'.
wa_salesqty = 1.
COLLECT wa_sales
INTO it_sales.
Explanation: COLLECT automates aggregation, improving
performance by eliminating the need for manual checks and additions.
9. APPEND LINES OF
vs. LOOPAPPENDENDLOOP
Use APPEND LINES OF to append one table to another, as
it’s faster than looping and appending each entry individually.
Example:
abap
Inefficient:
LOOP AT it_table1
INTO wa_table1.
APPEND wa_table1 TO it_table2.
ENDLOOP.
Optimized:
APPEND LINES OF
it_table1 TO it_table2.
Explanation: APPEND LINES OF handles the bulk append more
efficiently than looping through the records.
10. DELETE
ADJACENT DUPLICATES vs. READLOOPDELETE
DELETE ADJACENT DUPLICATES is much faster for removing
duplicates than looping through the table and deleting each duplicate manually.
Example:
abap
SORT it_customers BY
kunnr.
Inefficient
(Manual deletion):
LOOP AT it_customers
INTO wa_customer.
READ TABLE it_customers WITH KEY kunnr =
wa_customerkunnr.
IF sysubrc = 0.
DELETE it_customers.
ENDIF.
ENDLOOP.
Optimized (Using
DELETE ADJACENT DUPLICATES):
DELETE ADJACENT
DUPLICATES FROM it_customers COMPARING kunnr.
Explanation: The DELETE ADJACENT DUPLICATES operation is
optimized for removing duplicates after sorting.
11. DELETE ...
FROM ... TO ... vs. DODELETEENDDO
DELETE ... FROM ... TO ... is faster for deleting a range
of records compared to looping through the table and deleting each entry.
Example:
abap
Inefficient (Loopbased
deletion):
DO 5 TIMES.
DELETE it_customers INDEX syindex.
ENDDO.
Optimized (Rangebased
deletion):
DELETE it_customers
FROM 1 TO 5.
Explanation: Range based deletion is more efficient than
performing multiple deletions inside a loop.
12. Copying
Internal Tables
Copying internal tables using ITAB2[] = ITAB1[] is much
faster than using LOOPAPPENDENDLOOP.
Example:
abap
Inefficient:
LOOP AT itab1 INTO
wa_itab.
APPEND wa_itab TO itab2.
ENDLOOP.
Optimized:
itab2[] = itab1[].
Explanation: Direct table copying is optimized in ABAP,
avoiding the overhead of looping through each entry.
13. Typed
Parameters and FieldSymbols
Typed parameters and fieldsymbols are more efficient
because the system knows the types at compile time, allowing for better
optimization.
Example:
abap
Untyped fieldsymbol
(slower):
FIELDSYMBOLS:
<fs> TYPE ANY.
Typed fieldsymbol
(faster):
FIELDSYMBOLS:
<fs_customer> TYPE kna1.
Explanation: Typed fieldsymbols allow for better memory
management and faster execution.
14. CASE vs. IF
Statements
CASE is faster because it evaluates the condition once
and branches directly to the matching case, whereas IF evaluates each condition
sequentially.
Example:
abap
Inefficient (Using
IF):
IF var = 'A'.
" Do something
ELSEIF var = 'B'.
" Do something
ENDIF.
Optimized (Using
CASE):
CASE var.
WHEN 'A'.
" Do something
WHEN 'B'.
" Do something
ENDCASE.
15. WHILE vs. DO +
EXIT
Using WHILE is faster because it avoids the unnecessary
loop cycles and the need for an EXIT condition inside the loop.
Example:
abap
Inefficient (Using
DO + EXIT):
DO.
IF lv_counter > 10.
EXIT.
ENDIF.
ADD 1 TO lv_counter.
ENDDO.
Optimized (Using
WHILE):
WHILE lv_counter
<= 10.
ADD 1 TO lv_counter.
ENDWHILE.
16. Use Fields of Type I Instead of P
Fields of type I (integer) are faster for counting and
index operations than type P (packed number), which is designed for precise
calculations.
Example:
abap
Optimized (Using
type I):
DATA: lv_index TYPE
i VALUE 0.
17. Using Numeric
Literals for Integer Fields
For fields of type I or packed type P, always use numeric
literals instead of character strings, as numeric literals are more optimized.
Example:
abap
Inefficient:
lv_number = '1000'.
" Character string
Optimized:
lv_number = 1000.
" Numeric literal
18. String
Operations and Length Specification
Specifying the length of character fields instead of
using strings can improve performance in string operations.
Example:
abap
Optimized (Using
lengthspecified fields):
DATA: lv_text TYPE c
LENGTH 10.
lv_text = 'ABAP'.
19. Restrictive
Sort Keys
Always specify the sort key as restrictively as possible
to minimize sorting overhead.
Example:
abap
Inefficient
(Sorting on all fields):
SORT it_customers BY
.
Optimized
(Restrictive sort):
SORT it_customers BY
kunnr name1.
20. Hashed
Tables vs. Sorted Tables
For single read
access, hashed tables are faster as they provide constant time lookups.
For partial
sequential access, sorted tables are better because they allow efficient range
reads.
Example:
abap
Hashed table for
single read access:
DATA: it_customers
TYPE HASHED TABLE OF kna1 WITH UNIQUE KEY kunnr.
Sorted table for
partial sequential access:
DATA: it_customers
TYPE SORTED TABLE OF kna1 WITH UNIQUE KEY kunnr.
By following these optimization techniques, you can significantly enhance the performance of your ABAP programs, reducing execution time and resource consumption.
