If data objects of complex data types have many deep components, which often, for example, applies for internal tables with a deep row type, you have to consider that the administration costs in the form of memory for references and header do not grow disproportionately large compared to the actual data content.
For complex data objects with relatively little data content, we can distinguish three basic cases:
Deep data objects with a fill level that is sparse, duplicative, and not too low are generally harmless.
For deep data objects with a sparse fill level and few duplicative parts , you have to especially consider the memory requirements for references and headers. In contrast to other programming languages, ABAP is inaproppriate for a massive use of such data objects. You can possibly consider a class wrapping as alternative to internal tables at a low dataset level, as the extra costs for objects are comparatively on the lowest level.
An example for a duplicative data object with a low fill level can be an internal table whose row type is of table-type or contains table-type components. Even if the interior internal tables are initialized after prior usage, they still occupy memory for reference and header, which ,in the case of a large exterior internal table, can lead to a considerable memory requirement for only little or no work data at all.
The following program section illustrates the administration costs of deep components with little data content. At the breakpoint, you can display the memory requirements of the four internal tables itab, rtab, ttab and otab from the ABAP Debugger.
At the first breakpoint, the four tables have the same dynamic, but not duplicative data content, that is, 1000 different integer numbers. Whereas with itab only the administration costs for itab of roughly 100 byte must be added to the approximately 4 MB data content itself, the remaining tables produce administration costs for every table row. At the deep row types rtab, ttab and otab, the 4 MB data content is juxtaposed to 100, 200 and 300 MB of administration costs. The costs for the interior internal table in ttab are larger than the costs for the data reference in rtab, and the administration costs for otab consist of the costs for the object references and the internal tables in the referenced objects.
At the second breakpoint, all rows of the four tables were initialized with FREE. This does not influence the memory requirement of itab. At rtab, the data and all administration information of the individual reference variables were deleted, so that a memory requirement of approximately 8 MB for the initial references plus the administration costs for rtab itself remains. At ttab, the data was deleted, but the individual table headers persist, so that approximately 100 MB of effective administration costs remain, which is less than before, but still acceptable. otab behaves again like rtab and only produces the costs for the initial references.
On the one hand, the example illustrates that the administration costs for internal tables with deep row types can exceed the data content, and on the other hand, it illustrates that a table with object reference is more cost efficient than a table with interior tables - after deleting data.