Performance comparison By Naimesh Patel | March 11, 2013 | Performance | 2,422 | 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. Current Poll Do you like Quality Assurance of your Build/Design? YES. I live for it! I don't mind NO. I hate it Vote View Results Internal table without Secondary Keys Check out this demo program. I have declared a standard table without specifying any key. Im 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 Home Performance ZEVOLVING 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. 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.
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 steve oldner # March 12th, 2013 at 5:25 am 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! Naimesh Patel # March 12th, 2013 at 10:35 am 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 # April 9th, 2013 at 5:42 am how to improve writing the coding? please let me know . Naimesh Patel # April 9th, 2013 at 10:25 am 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 # April 29th, 2013 at 5:33 am Thanks Naimesh for this post. Nice tips for performance tuning.. More : Concepts , ITAB Performance , Performance , Secondary keys Naimesh Patel {240 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 240 articles. 5 Comments Comments on this Post are now closed. If you have something important to share, you can always contact me. Since 2008 | COPYRIGHT 2013 zevolving | www.zevolving.com | Advertise All product names are trademarks of their respective companies. zevolving.com is not affiliated with SAP AG.