Skip to Content
avatar image
Former Member

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

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.

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

3 Answers

  • Jan 11, 2017 at 10:49 AM


    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

    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    Jan 11, 2017 at 11:40 AM

    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

    Add comment
    10|10000 characters needed characters exceeded

  • Jan 11, 2017 at 08:25 PM

    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 (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.
    Add comment
    10|10000 characters needed characters exceeded

    • 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 ...