Skip to content

ABAP Keyword Documentation →  ABAP - Reference →  Processing Internal Data →  Internal Tables 

Internal Tables: Performance Notes

Other versions: 7.31 | 7.40 | 7.54

Table sharing

When assignments are made between internal tables of the same type whose row type does not contain any table types (for performance reasons), only the internal administration functions are passed to the table body. Table sharing is revoked only when change access to one of the tables involved is initiated. At this point, the actual copy process takes place.

Initial Allocated Memory Area

Internal tables are dynamic data objects whose area in the memory is increased block by block. The size of the first block in the memory can be controlled in the declaration of an internal table using the additions INITIAL SIZE and the obsolete OCCURS. If the first block is no longer enough, further blocks are created using an internal duplication strategy until a maximum size is reached. All additional blocks are then created with a constant size of between 8 and 16 KB.

In general, you can leave the system to determine the size of the first block (by not specifying INITIAL SIZE, or by entering the value 0). In this case, when the first rows are entered in an internal table, a suitable block size is chosen.

Entering a concrete value greater than 0 after INITIAL SIZE is only practical if you know in advance how many entries are to be made in the table, and you therefore want to create the first block with the most suitable dimensions. This can be particularly important for internal tables that are components of other internal tables, and which only contain a few rows (no more than around 5).

To avoid excessive memory demands, the system ignores values that produce memory demands greater than the constant block size.

Index Administration

In an index table, the logical order of the table entries is not generally consistent with the physical sequence of the entries in the main memory. In this case, the logical order is no longer administrated by a physical index, but by a logical index instead. The same is basically true for the secondary table indexes used to manage secondary sorted keys.

Use of the logical index produces additional memory requirements, and index maintenance places a high demand on resources (time and memory) when inserting or deleting table rows. The resource requirements rise in proportion to the number of remaining rows after the insertion or deletion position. For very large internal tables, this can result in considerable demands on performance at runtime.

The logical index is not created until the moment at which it is required, in other words, when a row is inserted before another row, if the order of the table rows is changed, or a row other than the last row is deleted. A logical index is not required if an internal table is filled using only APPEND, and if only its last row(s) is/are deleted using DELETE.


Note

In contrast to filling a table with INSERT, appending rows with APPEND does not require any resources for index maintenance. It is therefore preferable to use APPEND instead of INSERT to create a standard table. This is possible if the order of the entries is not important, or if entries can be appended in the correct order.

Block Processing of Table Rows

If whole row areas of a table can be processed at once, this should not be done in rows, but using block operations instead. Block operations are possible using the FROM and TO additions of the statements INSERT, APPEND and DELETE. Block operations are also more efficient than single record operations when reading from or modifying database tables with Open SQL statements with the additions FROM|APPENDING|TO TABLE.

Selective Data Transport

If, when reading table rows using READ TABLE or LOOP AT, a work area is used or table rows can be changed using MODIFY instead of by direct access, the TRANSPORTING addition can be used to prevent unnecessary assignments of table components to the work area. This can lead to a noticeable acceleration in performance, particularly if table-like components are excluded from processing.

Using Secondary Keys

The use of secondary table keys should be planned and executed with care. The time gained when accessing individual rows should not be lost again by the increased storage and time requirements for managing the secondary keys. Secondary keys are generally recommended for internal tables that are filled once and rarely changed during program execution.


Example

Program DEMO_SECONDARY_KEYS demonstrates the specification of a secondary table key and the resulting performance gain.

Deleting Table Rows

When you delete rows from an internal table, overhead is produced for all table keys and table indexes. The primary key and all unique secondary keys are updated directly, but non-unique secondary keys are updated only if the row being deleted is included in the updated part of an associated index (lazy update).

Also note that, for standard tables, the mean runtime of the statement DELETE always has a linear dependency on the number of table rows, even when secondary keys are specified using WITH TABLE KEY or USING KEY. This is because a linear search is required to update the primary index, even though the row being deleted can itself be found quickly.

Free Key Specification for Sorted Tables and Hashed Tables

When using the READ statement with a free key specification of the form WITH KEY ..., the search is optimized in all cases where this is possible:

  • In sorted tables, if any initial section of the table key or the complete table key is covered by the key specification.

If part of a free key meets these conditions, this partial key is first used to search for an entry. In sorted tables, this is performed using a binary search with a logarithmic consumption of resources, and in hashed tables by using a hash algorithm (that is, with constant resource consumption). If an entry is found, the system checks whether the rest of the key conditions are also met. This means that over-specific key specifications in particular are optimized.


Note

See also Optimization of the WHERE Condition.

Sorting

For textual sorting of an internal table in accordance with the current text environment, it is more beneficial for performance to use the statement CONVERT TEXT INTO SORTABLE CODE instead of SORT AS TEXT in the following cases:

  • If an internal table is sorted by locale and then subjected to a binary search using the statement READ TABLE or using a table expression.
  • An internal table must be sorted more than once.
  • Indices for database tables are to be structured in accordance with a locale.


This translation does not reflect the current version of the documentation.

Continue

Optimization of the WHERE Condition