ABAP Keyword Documentation → ABAP - Reference → Declarations → Declaration Statements → Data Types and Data Objects → Types and Objects - Overview → Data Objects → Memory Management of Deep Objects
Complex Data Objects with Deep Components
If data objects of complex data types have many deep components, which often, for example, applies to internal tables with a deep row type, you have to make sure 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:
A complex deep data object is sparsely populated if it contains many deep components of which a majority is initial. The required memory of such a deep initial component is 8 bytes, unless the component does not yet refer to a header.
A complex deep data object has a duplicative fill level if it contains many deep components of which a majority refers to the same data. Such components share the dynamic memory and only contribute to their references with the required memory. For dynamic data objects, this is achieved by sharing.
A complex deep data object has a low fill level if it contains many deep components that refer to different objects, strings or internal tables in which the objects only require very little memory or are empty.
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. Unlike other programming languages, ABAP is inappropriate for a massive use of such data objects. You can possibly consider a class wrapping as an alternative to internal tables at a low dataset level, since the extra costs for objects are comparatively low.
Other versions: 7.31 | 7.40 | 7.54
Example
An example of a duplicative data object with a low fill level is an internal table whose row type is itself table-like or contains table-like 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 considerable memory requirements for little or no work data.