Performance issues are often linked to database selection steps, however they needn't always be... Find out how the performance of handling internal tables can be dramatically improved... Once you are used to picking up selection results from a SELECT statement directly in to an internal table, the internal table itself could become a bottle-neck in performance.
Use sorted tables
The sorted table is geared up internally as a table that ensures fast access to the data. Improvements have been measured to be 500 times faster (!).
How ?
First define your internal table as a sorted table and specify it's key (which does not need to be unique). Example:
TYPES: BEGIN OF ty_record,
fld01 like ekko-ebeln,
fld02(20),
END OF ty_record.
DATA: i_normal_table TYPE TABLE OF ty_record,
i_sorted_table TYPE SORTED TABLE OF ty_record
WITH UNIQUE KEY fld01.
Then perform your selection, e.g. by selecting into the sorted table directly. Sorted tables can also be APPENDED to, as long as you keep it sorted. Use the INSERT to avoid having to worry about sequence, the statement will keep it's sorted table sorted. Sorted !
Note that a READ from a sorted table does not allow the BINARY SEARCH option - because a sorted table is already geared up with it's own search mechanisms.
Also note: it is possible to define multiple keys (unique or not) on your internal table, much like defining indexes on a transparent table.