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.
Suhas Saha replied
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.