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

##### Tags:

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