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
SELECT
statements
Never put aSELECT
statement inside theSELECT... ENDSELECT
block of another select statement. Whenever a database request is generated by an ABAP (typically aSELECT
statement 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
SELECT
statement in a loop
Even when it's aSELECT SINGLE
. Generally it should be possible to do the selection before the loop e.g. By doing aSELECT INTO TABLE
, placing the result into an internal table. This internal table can then beREAD
within the loop. - Use
SELECT INTO TABLE
andFOR ALL ENTRIES
where possible
Your development should really not have anENDSELECT
at all, usingSELECT SINGLE
,SELECT INTO TABLE
andFOR ALL ENTRIES
should cover every possible selection requirement you may have.
Note:FOR ALL ENTRIES
works 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
WhenSELECT *
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 theORDER BY
clause, 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 transactionSE11
for 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.