Hello fellow ABAPers, this is the first post in the SAP ABAP Perfection series, aiming to help you fix those performance issues you face regularly.
Have you faced performance issues with your programs lately?
Are you working with huge sets of data (usually not expected in test systems but proving to be a nuisance in productive ones) ?
Do you have a lot of programs in your SAP system which regularly go into long run?
I, like the most of us, in our project or support life-cycle, have faced these situations. We spend loads of efforts and man hours trying to find out why and what caused this sudden performance problem. Sometimes the problem becomes so critical that entire production lines are required to stop due to job failures or long running jobs. This has serious financial consequences for your company or client.
The Good News -
Now that I have shared the worst of the situations with you, time for some good news. All these performance problems can be fixed and avoided easily by using the following statements correctly -
Let's discuss the READ TABLE statement
In this discussion, I will give you a few hints on how to use the READ TABLE statement correctly. These hints can be applied to 90% of the times you use the statement. For the remaining 10%, please refer to the documentation of READ TABLE in the SAP documentation (F1 Help).
What does the Read Table statement do?
Put simply, the Read Table statement is used to read the contents of a single row of an internal table. Optionally, it can use user given conditions to pinpoint the exact row required by the user.
Which other ABAP statement has a similar functionality?
The LOOP AT statement (and it's modifications) in ABAP can also be used to read the contents of an internal table.
What is the difference between READ TABLE and LOOP AT statement?
The LOOP AT statement will always do a linear search (read each entry one by one) to find the correct entry matching the user given conditions. While the READ TABLE statement can make use of the binary search technique (divide and search) to find the correct entry. The binary search option is substantially faster as the number of entries in the internal table grows. As a comparison of the speed: to search a list of one million items takes as many as one million iterations with linear search, but never more than twenty iterations with binary search.
What are the best ways to use READ TABLE?
Now that we already know that the Read Table statement is superior than the Loop At statement as far as searching is concerned, let us dwell on the best ways to use the Read Table statement.
If you keep these easy to use options in mind and implement them in your programs, then you will notice a definite increase in performance. The larger the data set you are working with, the greater the performance increase.
With these suggestions, I leave you to ponder over them and maybe try and implement them in one of your demo programs to see the difference.
Have you faced performance issues with your programs lately?
Are you working with huge sets of data (usually not expected in test systems but proving to be a nuisance in productive ones) ?
Do you have a lot of programs in your SAP system which regularly go into long run?
I, like the most of us, in our project or support life-cycle, have faced these situations. We spend loads of efforts and man hours trying to find out why and what caused this sudden performance problem. Sometimes the problem becomes so critical that entire production lines are required to stop due to job failures or long running jobs. This has serious financial consequences for your company or client.
The Good News -
Now that I have shared the worst of the situations with you, time for some good news. All these performance problems can be fixed and avoided easily by using the following statements correctly -
- The SELECT statement
and,
- The READ TABLE statement
Let's discuss the READ TABLE statement
In this discussion, I will give you a few hints on how to use the READ TABLE statement correctly. These hints can be applied to 90% of the times you use the statement. For the remaining 10%, please refer to the documentation of READ TABLE in the SAP documentation (F1 Help).
What does the Read Table statement do?
Put simply, the Read Table statement is used to read the contents of a single row of an internal table. Optionally, it can use user given conditions to pinpoint the exact row required by the user.
Which other ABAP statement has a similar functionality?
The LOOP AT statement (and it's modifications) in ABAP can also be used to read the contents of an internal table.
What is the difference between READ TABLE and LOOP AT statement?
The LOOP AT statement will always do a linear search (read each entry one by one) to find the correct entry matching the user given conditions. While the READ TABLE statement can make use of the binary search technique (divide and search) to find the correct entry. The binary search option is substantially faster as the number of entries in the internal table grows. As a comparison of the speed: to search a list of one million items takes as many as one million iterations with linear search, but never more than twenty iterations with binary search.
What are the best ways to use READ TABLE?
Now that we already know that the Read Table statement is superior than the Loop At statement as far as searching is concerned, let us dwell on the best ways to use the Read Table statement.
- Always use the INDEX option or the BINARY SEARCH option wherever possible
- When using BINARY SEARCH, make sure that the internal table is sorted with those keys
e.g.:
Read using INDEX option
READ TABLE [itab] INTO [variable] INDEX 1.
The above statement is going to read the contents of row 1 (as INDEX 1 is being read) of internal table [itab] and store it in the [variable]. This means that the user is requesting the Read Table to fetch the contents of row 1 directly without searching the internal table. This statement can be used in situations where we are sure that only the first (or any specific entry) is required to be read.
e.g.: We have a list of Sales Orders in internal table [itab_so] and we want to read the details of the latest Sales Order. In such a case, we can easily sort the [itab_so] in descending order of the creation date and read the first entry in it. This means that once we have sorted the [itab_so] in descending order, we are sure that we will require only the first entry (or INDEX 1) of the internal table.
Read using the BINARY SEARCH
SORT [itab] BY [key_1].
READ TABLE [itab] INTO [variable] WITH KEY [key_1] = [variable_1] BINARY SEARCH.
The above READ TABLE statement is going to search for the entry in [itab] where the field [key_1] matches the [variable_1] input given by the user. The search algorithm to be used here is binary search as specified by the final section of the statement. As already mentioned in a previous section, sorting is mandatory when using binary search.
Conclusion
If you keep these easy to use options in mind and implement them in your programs, then you will notice a definite increase in performance. The larger the data set you are working with, the greater the performance increase.
With these suggestions, I leave you to ponder over them and maybe try and implement them in one of your demo programs to see the difference.
