Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Performance of Reads

Former Member
0 Kudos

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.

1 ACCEPTED SOLUTION

SuhaSaha
Advisor
Advisor
0 Kudos
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.

7 REPLIES 7

christian_wohlfahrt
Active Contributor
0 Kudos

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

monami
Explorer
0 Kudos

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.

SuhaSaha
Advisor
Advisor
0 Kudos
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.

0 Kudos

A "trusted colleague" of mine did some tests (which I'm yet to fully understand) on 7.4 SP12 purporting to show that only hashed tables are the way to go... No sorted tables where you have to deal with millions of records was his conclusion in a nutshell...

cheers

Jānis

0 Kudos

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

0 Kudos

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 .

Jelena
Active Contributor
0 Kudos

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!