Skip to Content
avatar image
Former Member

Performance of Reads

I've read discussions on this Forum and others where it is suggested that a Read Statement must always be accompanied by a binary Search.
I also found this on SAP Technical ( SAPTechnical.COM - ABAP Performance Standards )

When reading a single record in an internal table, the READ TABLE WITH KEY is not a direct READ.  This means that if the data is not sorted according to the key, the system must sequentially read the table.   Therefore, you should:

o       SORT the table

o       use READ TABLE WITH KEY BINARY SEARCH for better performance.

I don't understand this as according to me unless it a Loop in Loop situation where a Parallel Cursor is to be used , the Binary Search together with the Sort, that is required for it would have a bigger hit on performance than a sequential read or a loop and exit.


Complexities of the algorithms

Sort                = O(nLog(n))  - Assumed that quick Sort is used
Binary Search = O(log(n))

Total Complexity = O ( n log^2 n )

Simple Read or a Loop and Exit  = n

Since clearly n has a lesser hit than n log^2 n , I've concluded that for a simple read required only once , it makes no sense to do a Sort and then a Binary Search as it will have a bigger hit on performance.

I've looked for this on the Forum but couldn't find the right question with the answer I needed .


PS: I'm assuming that I'm working with large enough data that complexities do become a factor.

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

5 Answers

  • Best Answer
    Nov 01, 2015 at 08:15 PM
    I'm assuming that I'm working with large enough data that complexities do become a factor.

    If that's the case, then you should consider using SORTED/HASHED tables instead of STANDARD tables. Is there any reason you should be using STANDARD tables?

    DELETE/READ/LOOP...WHERE constructs for these tables are optimized if the whole key or a partial key(left-justified) is used.

    I don't understand this as according to me unless it a Loop in Loop situation where a Parallel Cursor is to be used

    Another ABAP fad, if you use SORTED/HASHED tables you don't need parallel cursor.

    Add comment
    10|10000 characters needed characters exceeded

    • that only hashed tables are the way to go

      What if ....

      1. The developer cannot define a unique key for the internal table
      2. The developer wants to have an index-based access to the table

      You cannot use a HASHED table in these cases 😔

  • Nov 02, 2015 at 10:47 PM

    Oh dear... SAPTechnical content is almost 10 years old. You'll also find all kinds of posts on SCN with all kinds of crazy advice. When searching on SCN, please make sure to check the post date and also the credentials of the poster.

    If you have access to a system with ABAP 7.4 you'll find an improved documentation as well as better ABAP examples there. But even in the earlier versions I'd encourage to read the documentation and look at the examples available in ABAP Editor (there is the whole section for performance examples). Even better - set up a simple test program and try different options yourself.

    As Suhas correctly pointed out, use HASHED table type whenever possible. BINARY SEARCH helps when it's not feasible to use HASHED table type, but it makes a difference if dealing with rather large internal tables (you'd probably need thousands of records to see a tangible improvement). Your math doesn't seem to consider that we SORT table once and then READ multiple times (inside LOOP without EXIT), from what I see. But this is a typical scenario for binary search.

    Actually it looks like in 7.4 we can finally create indexes for the internal tables, so binary search should become obsolete altogether. Looking forward to it!

    Add comment
    10|10000 characters needed characters exceeded

  • Oct 31, 2015 at 04:08 PM

    Hi Jacob,

    I think your're right - in the rare case, you read very seldom, then a sort + binary search is slower than read w/o binary search.

    But usually you have quite a lot of reads - why would you select a lot of data, if you don't read them later -> then in general using table keys makes sense.

    BR, Christian

    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    Nov 01, 2015 at 04:56 AM

    Hi Jacob,

    I completely agree with Christian.For a simple read where there will be only 1 result, simple read will be faster than sort and binary search.

    In general however , we use sort and binary search where we are to have a quite a few number of hits, and the read is made on a large number of records.

    It seldom makes sense to do a sort and binary search if the table has less than 100 records.

    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    Nov 02, 2015 at 05:30 AM

    Hi,

    These are few things which i have experimented never mention explicit SORT always use a field name

    SORT<ITAB>BY<FIELD> this increases performance in sort

    To Increase performance In  READ BINARY SEARCH addition is one of the ways.

    In general  if you compare SORT + READ with READ  read will be better,but if you compare as a program which contains FOR ALL ENTRIES , DELETE ADJACENT  DUPLICATES ,READ, etc which have sort as a prerequisite then you will sure find a lot of difference in performance .

    Add comment
    10|10000 characters needed characters exceeded