Create Hashed Table in ABAP for Internal Table Performance
ABAP Code Inspector is a tool for ABAP performance optimization for detecting low performance operations on internal tables. For example programmer can detect ABAP code where sequential read access for a standard table is performed where a internal hashed table could be used.
I recently run ABAP Code Inspector to detect bottle necks which decreases the performance of one of my ABAP programs. What I got as first step from the code inspector is that I could have used ABAP Hash Tables for boosting performance besides using the pointers instead of using looping through internal tables using work spaces.
This ABAP tutorial shows how to create a new hashed table in ABAP to prevent low performance internal table operations like Read, Delete, etc when a standard internal table is used with high number of rows.
ABAP Code Inspector: Low Performance Operations on Internal Tables
When I run ABAP Code Inspector to check for performance issues related with an ABAP function module, the Code Inspector listed some issues related with low performance operations on internal tables.
Sequential Read Access for a Standard Table
When I double-click on the line, it leads me to the ABAP editor line where a possible low-performance code resides.
READ TABLE lt_maktx REFERENCE INTO lr_maktx WITH KEY matnr = s_proforma_items-matnr.
The ABAP data definition of the internal table lt_maktx was as follows which defines a standard indexed ABAP internal table.
TYPES :
BEGIN OF lty_maktx,
matnr TYPE matnr,
maktx TYPE maktx,
END OF lty_maktx.
DATA lr_maktx TYPE REF TO lty_maktx.
DATA lt_maktx TYPE TABLE OF lty_maktx.
Documentation for Sequential Read Access for a Standard Table
The ABAP Code Inspector documentation provides following information for such performance related error for sequential reads from a standard internal table.
When using the current statement for an internal table of type STANDARD, the system runs a sequential search. In extreme cases, this may cause the entire table to be read (internally). This can have a significant impact on performance if the table contains many entries.
This applies to the following statements:
Ways to improve performance:
1) Convert the standard table to a table of type SORTED or HASHED with the search fields as keys
2) Sort the standard table and then access it with READ TABLE ... BINARY SEARCH.
You can also use this statement to determine the starting point for a LOOP.
(Re)sorting a standard table is worthwhile only if, after the sort, at least 40 read accesses with READ TABLE ... BINARY SEARCH are carried out that use the sort key for access
3) Introduce a secondary table key (hash or sorted key). Remember that this type of key is associated with a certain overhead that is justified only by a relevant number of read accesses.
Message can be suppressed with pseudo comment "#EC CI_STDSEQ
ABAP Hashed Table instead of Standard Internal Table
Keeping in mind above suggestions by Code Inspector documentation and considering the access times for individual rows in tables compared for ABAP internal table types, I decided to change the type of my internal table.
Since my internal table has many rows which I read frequently within the ABAP function module that I'm tuning for performance, I decided to convert the standard table to a hashed table using matnr field as unique key. But how can I create a hashed table using ABAP for high performance internal table operations.
How to Create ABAP Hashed Table
A standard table can be converted into ABAP hashed table by using the following definition statement. Or you can create a new ABAP hashed table using below syntax.
DATA lt_maktx TYPE HASHED TABLE OF lty_maktx WITH UNIQUE KEY matnr.
What seperates a standard indexed internal table from a hashed table in ABAP is the unique key which is defined on the table definition for all data contained in it.
If all data can be uniquely addressed by referring a field in the table structure, reaching any row using the unique key field value takes always the same time regardless of the number of rows in the hashed internal table.
ABAP developers can use hashed tables to scale up their codes to prevent performance losses when high number of rows are stored in the internal tables.
