Which one is faster - the new read statement or the old read statement with binary search?

[Former Member]

I want to know which one of the following read statements are faster?

• New Statement

ls_xyz = lt_xyz[ zzyz = it_zzyz ]

• Old Statement

SORT lt_xyz BY zzyz.

READ TABLE lt_xyz WITH KEY zzyz = it_zzyz BINARY SEARCH.

Please explain with proper reasons.

[former_member186746]

Hi,

You can find out yourself by using a do 1M times. get run time field, etc.

From my own experience differences in sorting are way too small to put any effort into. Memory usage and database access are better areas to put time and effort into when streamlining processes.

Kind regards, Rob Dielemans

[horst_keller]

He could also find out by reading the documentation ...

😉

[Jelena]

Where he/she could also find information about different table types and then truly dazzle the interviewer.

[Former Member]

hi, it depends from the number of lines in the internal table.

1. case: O(n), well linear (if the internal table not a sorted/hashed table)

2. case: sort cost O(n*log(n)) + read cost O(log(n))=O(n*log(n)) well logarithmic depends.

I think, over 10.000 lines and many reads better the 2. case (or the 1. case with sorted table).

Kind regards, Mihaly Takacs

[Sandra_Rossi]

Your first sample is mostly equivalent to the second one only if lt_xyz in the first sample is a table declared using SORTED TABLE OF ... WITH NON-UNIQUE KEY zzyz, as it means a binary search will be implicitly used (you could also use a secondary sorted key, etc.)

(of course, there could be better optimizations depending on your data and your general algorithm, but it's not part of your question)

Excerpt from ABAP documentation http://help.sap.com/abapdocu_740/en/abentable_exp_itab_line.htm#%21ABAP_ALTERNATIVE_2%402%40 (alternative 2) :

• If the free key overlaps with some or all of the primary table key, the optimizations described under READ TABLE are performed when sorted tables and hashed tables are read.
• Unlike the statement READ TABLE with a free key specified, no binary searches can be forced for a table expression and it is not possible to specify explicit table key for optimizing searches using secondary keys.

[SuhaSaha]

"... it is not possible to specify explicit table key for optimizing searches using secondary keys"

I'm confused with this statement. One can specify the KEYNAME to read using the key. 😐

[horst_keller]

Alternative 1

... [KEY keyname INDEX] idx

That's the key for the index access to specify which (seondary) index is used.

Alternative 3

... KEY keyname [COMPONENTS] ...

That's the key for the table key access.

Alternative 2

... comp1 = operand1 comp2 = operand2 ...

This is what this thread is about, the free key access.

All parallel to READ TABLE, but no key specification and no binary search for free key in expressions ...