10-31-2015 5:45 AM
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.
11-01-2015 8: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.
10-31-2015 4: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
11-01-2015 4: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.
11-01-2015 8: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.
11-03-2015 5:31 AM
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
11-03-2015 9:45 AM
that only hashed tables are the way to go
What if ....
You cannot use a HASHED table in these cases
11-02-2015 5: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 .
11-02-2015 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!