ABAP Performance Considerations While Coding

Hey All, straight to the point.I am going to list out the issues which you might encounter while using some of the ABAP statements and also the solution to avoid each issue, these are more of a ABAP performance considerations which are need to take care by an ABAPer.

1. Select statement Inside Loop:

Issue: It is a thumb rule that we should not use select statement inside LOOP-ENDLOOP. It is a huge performance killer because the select query execution depends up on the number of times the loop executes.
Solution: We can avoid this by using for all entries statement as part of select query.

2. MODIFY inside a LOOP:

Issue: This is also a performance killer, we should avoid modify statement inside a loop. The reason same as above the execution of select query depends up on the number time the loops executes.
Solution: Instead of using work area for looping we can use field symbols work are without using modify statement. The changes made to the field symbols work area will automatically reflects the internal table data.

3. READ Statement:

Issue 1: By default ‘READ’ statement follows linear search i.e. It searches for the required record from the beginning of the internal table to the end.
Solution: Use ‘BINARY SEARCH’ option as part of ‘READ’ statement so the searching will start from middle of the internal table.

Pre-requisite to use ‘BINARY SEARCH’:
Sort the internal table on the searching fields before using binary search. Otherwise does not have any effect.

Issue 2: READ statement by default reads all the fields of a record from internal table to work area.

Solution: If you do not need the data of all the fields in the internal table use ‘TRANSPORTING’ option for specific fields from body to work area.

TIP: To check the existence of a record in an internal table use ‘TRANSPORTING NO FIELDS’ as part of ‘READ’ statement, if sy-sbrc is 0 record found.

4. Use ‘CASE — END CASE’ Instead Of Multiple ‘IF’s:

Issue: IF statement executes one after the other until one of the conditions satisfied.

Solution: Instead of ‘IF’ used CASE — END CASE so that control directly jumps to the appropriate ‘WHEN’ statement where it satisfies the variable value.

5. INTO CORRESPONDING FIELDS In Select Query:

Issue: Sometimes using this statement in select query decreases the performance and often lead to run-time error. Because while copying the data to the target structure or internal table it checks for the matching fields.
This comparison consumes time and apart from this if any matching field is found it directly copies the data without checking for DATA types. If the DATA types are not compatible, it leads to run-time error.

Solution: To avoid this we need to declare the same sequence of fields as it is in database tables, same field names and data types in the target structure or internal table.

6. Using ‘ Select * from’:

Issue: We should maximum try to avoid ‘select * from‘ when there is no necessity of fetching all the fields.

Solution: You can specify the field name which needs to retrieve and this sequence should match with the target structure or internal table.

7. Using Joins in Select Queries:

Issue: This increase the load on database because the data needs to be retrieved from multiple tables based on the join condition.

Solution: Create a database view based on multiple tables by providing the join conditions.

8. TABLES Keyword:

Issue: When we declare the select option my referring to a dictionary field we must declare the dictionary structure with the ‘TABLES’ keyword.
This declares the work area based on the fields of the dictionary structure which is little memory consuming.

Solution: Declare a local variable by referring to dictionary field and then declare the select options referring to the local variable.

9. Fields Referring to Dictionary:

Issue: Whenever a field needs to refer to a dictionary it is recommended not to hard code the data type and size because in future if the dictionary field properties are modified then we need to modify the corresponding declaration across the programs. This increases the maintenance cost.

Solution: Either declare the variable by referring directly to the dictionary field or refer to data element. So that even if the dictionary field properties are modified we need not modify the corresponding declarations.

10. Open SQL Vs Native SQL:

Issue: When we use native SQL as part of select statements it increases the maintenance cost.
Because in future if the database is changes we must modify the corresponding select statements to the native SQL of the new database this increases maintenance cost.

Solution: Always use Open SQL so that even if the data base changed we don’t have to worry about the coding changes.

11. Internal Tables in Select Queries:

Issue: When we try to retrieve the data into an internal table, which is already holding the data, the old data is deleted by the system.

Solution: If we do not need the old data then we can use refresh the internal table explicitly using in the select query.
If the old data is required, we need to use ‘APPENDING CORRESPONDING FIELDS’ as part of select query to append the new data with the old data.

TIP: To avoid ‘APPENDING CORRESPONDING FIELDS’, retrieve the data into temporary internal table and append the same to the existing internal table by using ‘APPEND LINES’ statement.

12. FOR ALL ENTRIES:

Before using FOR ALL ENTRIES we should check the non-emptiness of the source internal table else the select query fetches all the data from table.

13. Smart Forms:

While calling the ‘smart form’ from a driver program it is good to directly call the smart form function module because the smart form function module depends up on the client numbering format of the individual clients.

Solution: To avoid this we need to generate the smart form function module’s name dynamically using ‘SSF_FUNCTION_MODULE_NAME’.

14. Using ‘OCCURS’ :

Issue: This statement allocates static memory.

Solution: Use standard table based on the types declaration.

15. Loop Inside Loop:

Issue: The statements execution inside loop depends up on the number records inside a loop which leads to performance issue.

Solution: Use parallel cursor technique if there is a situation we can’t avoid a loop inside a loop.

Tips for Better ABAP Coding:

1. For data migration, use standard BAPIs provided by SAP if available.
2. BADIs: It is recommended to do enhancements using BADIs instead of customer exists, BADIs are performance wise really faster.
3. Clear work areas after use.
4. When processing large amount of data, it is recommended to use hashed internal tables rather than standard internal tables.
5. Use ‘SELECT UPTO 1 ROW’ instead ‘SELECT SINGLE’ when full primary key combination is un known.
6. Always follow the naming conventions for variables, work area, internal table, field symbols, constants, Types declarations, select options.
7. It is recommended to set the break point manually instead of keyword ‘BREAK-POINT’.
8. Avoid repeated code and try to modularize the program by using subroutines, F.M’s and Methods.
9. Go for explicit work areas instead of declaring the internal table with header line
10. Always specify as many as primary keys as possible in the where condition of the select statement to make it efficient.
11. Try to create secondary indexes on the database table when there is select statement which needs to compare with non-primary key.
12. Before updating any business objects try to lock the object perform the operations and release the object.
13. To refresh the internal table or work area use ‘CLEAR’ instead of ‘FREE’ or ‘REFRESH’ which are obsolete.
14. Replace obsolete statement and delete un-used variable using ‘Extended Program Check’.
15. After developing the object, we need to use different tools to identify performance issues, security issues, obsolete statements, non-coding standards, un-used variable etc.