When you assign internal tables using itab1 = itab2, the data of itab2 is not copied physically. The data is only copied if you access one of these tables in change mode.
Internal tables are a dynamic data structure. Their memory requirements are met in blocks. The initial memory allocation (hereafter called the OCCURS area), can be controlled using the " OCCURS n" or "INITIAL SIZE n " addition in the table definition (see DATA, TYPES). Once the OCCURS area is full, the next block to be created is twice as big as the OCCURS area (as long as this is not greater than 8 KB). All further blocks are then created with a constant size of 12 KB.
You can leave it to the system to determine the size of the OCCURS area by specifying n = 0. In this case, the system allocates only a "small" portion of memory at the first INSERT or APPEND statement. "OCCURS 0" or "INITIAL SIZE 0" means that 16 <= n <= 100 (depending on the line width).
It only makes sense to specify a concrete value of n > 0 when you know exactly how many entries the table will have, and you want to set up the OCCURS area exactly. This can be particularly important if you want to nest internal tables (where an "outer" internal table contains one or more other internal tables in each line, and the "inner" tables only have a few entries (no more than 5, for example).
To avoid excessive memory requirements, the system handles large values of n as follows: The largest possible value of n is n_max = 8 KB divided by the line width. For larger values, n is set such that n multiplied by the line width is around 12 KB.
As soon as you change an internal table using
INSERT, DELETE
or SORT, the logical sequence
of the table entries will no longer correspond with the physical sequence in the memory. When this happens,
the system creates a logical index, which also requires memory. Furthermore, each
INSERT or DELETE
statement requires further memory. If your internal table is very large, changing the index can result in significantly increased runtime.
The system does not administer secondary indexes for internal tables.
Unlike filling a table using the INSERT statement, using APPEND does not cost runtime in terms of maintaining the index. If the sequence of the entries is unimportant, or they are already in the correct order, you should use APPEND instead of INSERT.
If you want to add or append whole blocks of a table to an internal table, you should do this using
the following block operations, not line-by-line:
INSERT LINES OF itab1 [FROM i] [TO j] INTO itab2 [INDEX k]. or
APPEND LINES OF itab1 [FROM i] [TO j] TO itab2.
If you want to read several records from an internal table into a database table using SELECT, you should not do it record-by-record, but using the INTO TABLE or APPENDING TABLE additions.
If you want to change individual fields of one or more database tables, you can transport fields selectively using the TRANSPORTING f1 ... fn [WHERE cond] addition. This can increase performance considerably in comparison with a simple MODIFY statement, in which the whole work area is copied back into the table. This applies particuarly if you exclude components that are themseleves tables using the TRANSPORTING addition. You can also speed up the frequent task of resetting a flag for all lines meeting a certain condition by using MODIFY ... TRANSPORTING.