ABAP Internal Table Secondary Key Performance comparison

By | March 11, 2013 | Performance | 5,566 | 5

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.

Measure the performance of the Table without Secondary Key

 
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.

Measure the performance for the Table With Secondary key

 

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…

Like It? Share!!

Don't miss an Update

Get notified of the new post, right into your inbox

Naimesh Patel{272 articles}

I'm SAP ABAP Consultant for more than a decade. I like to experiment with ABAP especially OO. I have been SDN Top Contributor.
Follow :

Explore all of his 272 articles.

Load comments

5 Comments

  • steve oldner

    Very nice and informative. I am very glad you added the sort to the time so we can see ‘real’ coding examples. Not much different with sorting the itab and then using binary search – 00329 vrs 00362.

    For others reading this, the actual time depends on the system, so it does vary. For myself, I run my tests 4 times to average it out. Thus 329 – 362 as a 1 time run is close enough!

    .Again, thanks for the article!

  • Hello Steve,

    SORT has be to always considered when we need to evaluate Normal Read vs Binary Read. Without SORT, the results would be incorrect.

    I agree with the Time difference on various different systems.

    Regards,
    Naimesh Patel

  • silpa

    how to improve writing the coding? please let me know .

  • Hello Silpa,

    It is very wide and generic question. You always need to look for new techniques while you write the code. Also, you need to use the tools like Extended Program Check (SLIN) & Code Inspector (SCI) to fix any errors. You would also need to do the performance analysis of your code using various tools – ST12, ST05 etc.

    Good Luck.

    Thanks,
    Naimesh Patel

  • Rajeev

    Thanks Naimesh for this post. Nice tips for performance tuning..

Comments on this Post are now closed. If you have something important to share, you can always contact me.

You seem to be new here. Subscribe to stay connected.