You've optimized your select, used joins and internally buffered using internal tables and binary reads. Now supercharge...
the performance by using hashed internal tables with direct reads instead of binary searches!
If the internal tables you are working with have unique keys, and are referenced as part of your code, you should find that defining the tables as Hashed tables are the logical choice when building and utilizing internal tables with unique indexes that are to be referenced later and include large amounts of data. This is the most efficient way of managing the internal data and minimizing access time. Using hashed internal tables the 100,000th record is read just as quickly as the 1st making it much faster than even a binary search.
-------------------------------------- * declare the table as type hashed. TYPES: BEGIN OF LINE, COL1 TYPE I, COL2 TYPE I, END OF LINE. DATA: ITAB TYPE HASHED TABLE OF LINE WITH UNIQUE KEY COL1, WA LIKE LINE OF ITAB. * example inserting data into the table DO 4 TIMES. WA-COL1 = SY-INDEX. WA-COL2 = SY-INDEX ** 2. INSERT WA INTO TABLE ITAB. ENDDO. * assign key and read record WA-COL1 = 2. READ TABLE ITAB FROM WA INTO WA. * assign new value and modify record WA-COL2 = 100. MODIFY TABLE ITAB FROM WA. * assign key and delete record WA-COL1 = 4. DELETE TABLE ITAB FROM WA. * display contents LOOP AT ITAB INTO WA. WRITE: / WA-COL1, WA-COL2. ENDLOOP. ********************************** The list is as follows: 1 1 2 100 3 9 *