Copyright 2022 - BV TallVision IT

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 !

  1. Avoid nested SELECT statements
    Never put a SELECT statement inside the SELECT... ENDSELECT block of another select statement. Whenever a database request is generated by an ABAP (typically a SELECT 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. 
  2. Select within a loop: never put a SELECT statement 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 READ within the loop.
  3. Use SELECT INTO TABLE and FOR ALL ENTRIES where possible
    Your development should really not have an ENDSELECT at all, using SELECT SINGLESELECT INTO TABLE and FOR 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 !
  4. 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 !
  5. Specify field names in your SELECT statement
    When 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 BY clause, as it consumes processor time.
  6. 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.
  7. Utilise indexes
    To improve the performance of your development where database selection are concerned, indexes can be used. Via transaction SE11 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).
  8. 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.