Performance tuning your developments can be a matter of applying some guidelines. Any developer should adhere to them as part of quality development. Do sing along !
- Avoid nested
Never put a
SELECTstatement inside the
SELECT... ENDSELECTblock of another select statement. Whenever a database request is generated by an ABAP (typically a
SELECTstatement call), a block of many Kb's is moved across the network. Whenever the database "answers", a similar block of data is passed back again. Performance tuning is much about limiting the number of data blocks that are copied across the network, thus ensuring that this is only done where and when necessary. The nested select is a very effective performance killer because it consumes so many data block moves.
- Select within a loop: never put a
SELECTstatement in a loop
Even when it's a
SELECT SINGLE. Generally it should be possible to do the selection before the loop e.g. By doing a
SELECT INTO TABLE, placing the result into an internal table. This internal table can then be
READwithin the loop.
SELECT INTO TABLEand
FOR ALL ENTRIESwhere possible
Your development should really not have an
ENDSELECTat all, using
SELECT INTO TABLEand
FOR ALL ENTRIESshould cover every possible selection requirement you may have.
FOR ALL ENTRIESworks as a table of restrictions. This means that the internal table defines to select from should never be empty !
- Intelligent internal table usage
Internal tables can be defined as sorted tables or table with a key. Abap processing on these (internal) tables is dramatically faster !
- Specify field names in your SELECT statement
SELECT *is used, all fields will be copied across, while often only a few of the available fields are required. E.g. The purchase order item actually has 236 fields which adds up to over 1500 bytes. When you specify the fields you need, only these fields will be copied from database to your program. Also refrain from using the
ORDER BYclause, as it consumes processor time.
- Keep select statements grouped together
Actual database connections can "time out" so when your selections are scattered all over your source code (at runtime), new database connections need to be established. Try to do all relevant selections together.
- Utilise indexes
To improve the performance of your development where database selection are concerned, indexes can be used. Via transaction
SE11for a table, the button "Indexes" reveals available indexes which will automatically be used when all index fields are specified in your selection. Indexes can also be added, in extreme cases (as the system maintenance for the index is itself performance sensitive).
- Use joins
When muliple tables are invloed in your selection, linking them together in < code>JOIN can be a strong performance improver. Leave the heavy selection logic to the database, where it has been optimized for you.