When assignments are made between tables whose actual line type does not contain any table types, as of release 6.10 only the internal administration functions are passed to the table body - for performance reasons. Sharing is removed only when change access to one of the tables involved is initiated. Then the actual copy procedure takes place.
Internal tables are dynamic data objects for which the area in the memory is extended in blocks. The size of the first block in the memory can be controlled in the declaration of an internal table using the additions INITAL SIZE and the obsolete OCCURS. When the first block is no longer sufficient, the next block is created with twice the size, as long as this does not exceed the limit of 8 KB. All additional blocks are then created with a constant size on a scale of 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, the first time lines are entered into an internal table, a block size is chosen that corresponds to a value from 16 to 100 after INITAL SIZE, depending on the line width.
Entering a concrete value greater than 0 after INITAL 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 lines (no more than around 5).
To avoid excessive memory demands, the system converts values that are too large as follows: The largest possible value is the result of 8 KB divided by the memory requirement for one line. For larger values, a block size to the scale of 12 KB is chosen.
In an index table, the logical sequence of the table entries is not generally consistent with the physical sequence of the entries in the main memory. In this case, the logical sequence is no longer administrated by a physical index, but by a logical index instead. Secondary indices, such as are available for database tables, are not supported for internal tables.
Use of the logical index results in additional memory requirements, and index maintenance places a high demand on resources (time and memory) when inserting or deleting table lines. The resource requirements rise in proportion to the number of remaining lines 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, i.e. when a line is inserted before another line, if the sequence of table rows is changed, or a line other than the last line is deleted. A logical index is not required if an internal table is filled using only APPEND, and if only its last line(s) is/are deleted using DELETE
In contrast to filling a table with INSERT, appending lines 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.
If whole line areas of a table can be processed at once, this should not be performed in lines, 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 Open SQL statements with the additions FROM|APPENDING|TO TABLE.
When reading table rows using READ TABLE or LOOP AT, if 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-type components are excluded from processing.
When using the READ statement with a free key entry in the form WITH KEY ..., the search is optimized in all cases in which this is possible:
If part of a free key fulfills 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, using a hash algorithm, or with constant resource consumption. If an entry is found, the system checks whether the rest of the key conditions are also fulfilled. This means that over-specific key specifications in particular are optimized.
Partially sequential set access takes place when the WHERE addition is used in the statements LOOP AT, DELETE and MODIFY. Partially sequential access to sorted tables is optimized if
As in the optimization when reading with a free key using READ, the starting point for the loop is determined using a binary key with the partial condition that is partially or fully covered by the table keys. From the starting point onwards, the loop is only processed for as long as these partial conditions remain fulfilled.
For textual sorting of an internal table according to 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: