Sorting an already sorted internal table in ABAP

When working with internal tables in ABAP, sorting performance can be optimized by understanding how sorting affects subsequent operations. If you leave the second sort operation, it would be quicker as the internal table (itab) will already be in the right order.

Sorting and Binary Search Example

Consider the following example where we sort by multiple fields and then perform binary searches ?

SORT itab BY f1 f2 f3.
READ TABLE itab WITH KEY f1 = 'A'
   f2 = 'B'
   f3 = 'C' BINARY SEARCH.
READ TABLE itab WITH KEY f1 = 'A' BINARY SEARCH.

In this example, after sorting by f1 f2 f3, both READ TABLE operations can use BINARY SEARCH effectively because the table is sorted according to the search keys.

Performance Considerations

When the second READ TABLE operation searches only by f2, you should omit both the SORT and BINARY SEARCH operations. This is because binary search requires the table to be sorted by the search key, and sorting by f1 f2 f3 doesn't guarantee proper ordering for searches by f2 alone.

Performance complexity:

• Best case scenario: SORT + BINARY SEARCH has complexity of n + log(n)
• Worst case scenario: SORT operation has complexity of n log n

Where n is the number of entries in the internal table. Binary search is only beneficial when the table is properly sorted according to the search criteria.

Conclusion

Understanding the relationship between sorting and binary search operations helps optimize ABAP performance by avoiding unnecessary sorts and ensuring binary searches are used only when the table is appropriately ordered.