Ansicht
Dokumentation

ABENITAB_PERFO - ITAB PERFO

PERFORM Short Reference   CL_GUI_FRONTEND_SERVICES - Frontend Services  
This documentation is copyright by SAP AG.

- Performance Notes

Table Sharing

When assignments are made between internal tables of the same type whose line type does not contain any table types, only the internal administration functions are passed to the table body for performance reasons. Table sharing is revoked only when write access to one of the tables involved is initiated. The actual copy process then takes place.

Initial Allocated Memory Area

Internal tables are dynamic data objects whose area in the memory is extended 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 sufficient, 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.

It is usually up to the system to determine the size of the first block (by not specifying INITIAL SIZE, or by specifying 0). In this case, a suitable block size is chosen the first time lines are added to an internal table.

Specifying 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 lines (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 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. The same basically applies to 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 lines. The resource requirements increase proportionally with 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 only created when it is needed, that is, when a line is inserted in front of another line, if the order of the table lines 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 onlyAPPEND, and if only its last line or lines is/are deleted using DELETE.

Note

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.

Block Processing of Table Lines

If entire line areas of a table can be processed at once, this should not be done line-by-line, but using block operations. 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 statements with the additions FROM$|APPENDING$|TO TABLE.

Selective Data Transport

If, when reading table lines using READ TABLE or LOOP AT, a work area is used or table lines can be changed using MODIFY instead of 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 improvement 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 carefully and sparingly. The time gained when accessing individual lines should not be lost again by the increased memory 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

The program DEMO_SECONDARY_KEYS demonstrates how a secondary table key is specified and the resulting performance gain.

Deleting Table Lines

When lines are deleted from an internal table, administration costs are incurred 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 line to be deleted is included in the updated part of an associated index (lazy update).

It should be noted that, particularly for standard tables, the mean runtime of the statement DELETE always depends linearly on the number of table lines, 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 line to be deleted can itself be found quickly.

Deleting lines in internal tables using DELETE does not usually release any memory in the internal table. Statements such as CLEAR or FREE must be used to release memory in internal tables.

Free Key Specified for Sorted Tables and Hashed Tables

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

• 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 done using a binary search with a logarithmic consumption of resources, and in hashed tables 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.

Note

See also Optimization of the WHERE Condition.

Sorting

For textual sorting of an internal table in accordance with the current text environment, it can be more efficient 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 searched binarily using the statement READ TABLE or 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.

CL_GUI_FRONTEND_SERVICES - Frontend Services   Fill RESBD Structure from EBP Component Structure  
This documentation is copyright by SAP AG.

Length: 10427 Date: 20240427 Time: 024612     sap01-206 ( 186 ms )