I do know a lot of you may never have lived the times before 4.x and the new kernel optimizations, but please remember a few basic performance rules:
When dealing with an internal loop table:
1) Always do a sort of the internal loop table outside of the external loop.
2) If it is not possible to work only with indexes and especially when the external loop table cannot be sorted, it is always advantageous to determine the index of the internal loop table before processing.
3) Banish LOOP AT itab WHERE for the internal loop table.
Way to costy: (x = n * m vs x >= 2m).
4.x kernel optimization will allow you LOOP AT TABLE itab WHERE and optimize in the kernel. But do this with 3.x system and you're dead in the water when processing volume.
Well I don't want to be to bothersome but it seems an example would be appropriate:
Bear with me this one is from memory.
Application logic does not allow you to resort table itab1. You have to process what you get.
For each record in itab1 process the corresponding records in itab2
Sort itab2 on key1. "ascending of course LOOP AT itab1 into ws1. * new 4.6 could use assigning <fws1>. READ TABLE itab2 WITH KEY key1 = ws1-key1 BINARY SEARCH TRANSPORTING NO FIELDS. * the following check avoids processing of orphan itab1 records CHECK SYST-SUBRC = 0. idx = SYST-TABIX. * note I have seen some SAP programs * use a slightly different form but * can't recall it from memory. * the spirit remains the same. LOOP AT itab2 INTO ws2 FROM idx. * Make sure you exit the loop * if the keys do not match IF ws2-key1 <> ws1-key1. EXIT. ENDIF. * process your records from itab2 here ENDLOOP. "itab2 ENDLOOP. "itab1