Internal Tables: Performance NotesOther versions: 7.31 | 7.40 | 7.54
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, the system can be left 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 it is known in advance how many entries are to be made in the table, and the first block is therefore
to be created 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.
In an index table, the logical order of the table entries is not generally consistent with the physical order 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
In contrast to filling a table with
appending rows with
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
TO additions of the statements
DELETE. Block operations are also more efficient than single record operations when reading from or modifying database tables with
ABAP SQL statements with the additions
Selective Data Transport
If, when reading table rows using READ
a work area is used or table rows can be changed using
MODIFY instead of by direct access, the
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.
The program DEMO_SECONDARY_KEYS demonstrates how a secondary table key is specified and the resulting performance gain.
Deleting Table Rows
When rows are deleted 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
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 Specified for Sorted Tables and Hashed Tables
- In sorted tables, if any initial section of the table key or the complete table key is covered by the specified key.
- In hashed tables, if the complete table key is covered.
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 keys in particular are optimized.
See also Optimization of the
For textual sorting of an internal table in accordance with the current
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 TABLEor using a table expression.
- An internal table must be sorted more than once.
- Indexes for database tables should be structured in accordance with a locale.
This translation does not reflect the current version of the documentation.