Performance is the driving factor when using the Secondary Keys on the ABAP Internal Tables. So, Lets check out ABAP Internal Table Secondary Key Performance comparison.

In last article, I show you how to declare and use Internal Table Secondary Keys which are available from ABAP 7.0 EhP2. In this article, I would try to capture the performance comparison between using Secondary Key and table without key.

Internal table without Secondary Keys

Check out this demo program. I have declared a standard table without specifying any key. I’m selecting few thousand entries from T100.

 
REPORT  ztest_np_no_secondary_key.
*&---------------------------------------------------------------------*
*& Purpose - Measure the performance of the Table without Secondary Key
*& Author  - Naimesh Patel
*& URL     - http://zevolving.com/?p=1950
*&---------------------------------------------------------------------*
*
* =======
TYPES:
  tt_t100 TYPE STANDARD TABLE OF t100.
*
DATA: t_t100 TYPE tt_t100.
DATA: lt_arbgb_range TYPE RANGE OF t100-arbgb.
DATA: ls_arbgb LIKE LINE OF lt_arbgb_range.
ls_arbgb = 'IBT'.
ls_arbgb-low = '00'.
ls_arbgb-high = '02'.
APPEND ls_arbgb TO lt_arbgb_range.
*
SELECT * FROM t100
  INTO TABLE t_t100
  WHERE sprsl IN ('DE','EN')
  AND   arbgb IN lt_arbgb_range.
*
DATA: ls_t100 LIKE LINE OF t_t100.
DATA: lv_sta_time TYPE timestampl,
      lv_end_time TYPE timestampl,
      lv_diff   TYPE p DECIMALS 5.
*
*---- 
GET TIME STAMP FIELD lv_sta_time.
READ TABLE t_t100 INTO ls_t100
  WITH KEY sprsl = 'EN'
           text  = 'Specify a program title'.
GET TIME STAMP FIELD lv_end_time.
lv_diff  = lv_end_time - lv_sta_time.
WRITE: /(60) 'Std Table - No binary search - Existent entry', lv_diff.
*
*----
GET TIME STAMP FIELD lv_sta_time.
READ TABLE t_t100 INTO ls_t100
  WITH KEY sprsl = 'EN'
           text  = 'XXX'.
GET TIME STAMP FIELD lv_end_time.
lv_diff  = lv_end_time - lv_sta_time.
WRITE: /(60) 'Std Table - No binary search - Nonexistent entry ', lv_diff.
*
*------
GET TIME STAMP FIELD lv_sta_time.
SORT t_t100 by sprsl text.
READ TABLE t_t100 INTO ls_t100
  WITH KEY sprsl = 'EN'
           text  = 'Specify a program title'
           BINARY SEARCH.
GET TIME STAMP FIELD lv_end_time.
lv_diff  = lv_end_time - lv_sta_time.
WRITE: /(60) 'Std table - Binary Search - Existent Entry', lv_diff.
*
*------
GET TIME STAMP FIELD lv_sta_time.
READ TABLE t_t100 INTO ls_t100
  WITH KEY sprsl = 'EN'
           text  = 'Specify a program title'
           BINARY SEARCH.
GET TIME STAMP FIELD lv_end_time.
lv_diff  = lv_end_time - lv_sta_time.
WRITE: /(60) 'Std table - Binary Search - Existent Entry', lv_diff.
 
 

I measure the performance for four different scenarios:

• Existent Key in a table without using Binary Search
• Non-Existent Key in a table without using Binary Search
• Existent Key in a table with using Binary Search
• Existent Key in a table with using Binary Search – 2nd pass

On an average the performance measurement look like this:

The hike in the 3rd reading is because of the SORT on the table which is essential before reading the table using BINARY SEARCH. On subsequent READ, it is very fast on retrieving the entry from the table.

Internal table with Secondary Keys

Now check another demo program. This program has a Primary Key of the table, which I wont be using for performance comparison. I declared a secondary key using the same fields which are used in the READ statements. I would be using this key to measure the performance.

REPORT ztest_np_PROTECTED.
*&———————————————————————*
*& Purpose – Measure the performance for the Table With Secondary key
*& Author – Naimesh Patel
*& URL – http://zevolving.com/?p=1950
*&———————————————————————*
*
* ——
TYPES:
tt_t100 TYPE STANDARD TABLE OF t100
WITH KEY sprsl arbgb msgnr
WITH NON-UNIQUE SORTED KEY lang_text “<< COMPONENTS sprsl text. * DATA: t_t100 TYPE tt_t100. DATA: lt_arbgb_range TYPE RANGE OF t100-arbgb. DATA: ls_arbgb LIKE LINE OF lt_arbgb_range. ls_arbgb = 'IBT'. ls_arbgb-low = '00'. ls_arbgb-high = '02'. APPEND ls_arbgb TO lt_arbgb_range. * SELECT * FROM t100 INTO TABLE t_t100 WHERE sprsl IN ('DE','EN') AND arbgb IN lt_arbgb_range. DATA: ls_t100 LIKE LINE OF t_t100. DATA: lv_sta_time TYPE timestampl, lv_end_time TYPE timestampl, lv_diff TYPE p DECIMALS 5. * *---- GET TIME STAMP FIELD lv_sta_time. READ TABLE t_t100 INTO ls_t100 WITH KEY lang_text COMPONENTS sprsl = 'EN' text = 'Specify a program title'. GET TIME STAMP FIELD lv_end_time. lv_diff = lv_end_time - lv_sta_time. WRITE: /(60) 'Secondary key - Valid Entry - First Pass', lv_diff. * *----- GET TIME STAMP FIELD lv_sta_time. READ TABLE t_t100 INTO ls_t100 WITH KEY lang_text COMPONENTS sprsl = 'EN' text = 'XXX'. GET TIME STAMP FIELD lv_end_time. lv_diff = lv_end_time - lv_sta_time. WRITE: /(60) 'Secondary key - Non Existant Entry', lv_diff. * *------ GET TIME STAMP FIELD lv_sta_time. READ TABLE t_t100 INTO ls_t100 WITH KEY lang_text COMPONENTS sprsl = 'EN' text = 'Specify a program title'. GET TIME STAMP FIELD lv_end_time. lv_diff = lv_end_time - lv_sta_time. WRITE: /(60) 'Secondary key - Valid Entry', lv_diff. [/abap_code] I measure the performance for three different scenarios:

• Secondary Key for a valid Entry – First Pass
• Secondary Key for a nonexistent entry
• Secondary Key for a valid Entry – Second Pass

Measurement for this program is something like this:

As you can see, system took more time for the first read. The reason behind this is Lazy Update – Non-Unique Secondary key only got refresh as I mentioned in the previous article ABAP Internal Table Secondary Keys, New in ABAP 7.0 EhP2 when it was first accessed. After the first pass, the key and its internal administration is set, which we can notice in subsequent reads.

Conclusion

Internal table with Secondary key would be definitely faster than alternatives as it is managed internally by internal table administration.

On Graph…