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, the management costs (in the form of memory) for references and headers must be prevented from growing 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 memory requirement of a deep initial component like this is 8 bytes, unless the component does not yet point 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, it is vital to 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 inner internal tables are initialized after prior usage, they still occupy memory for reference and header, which, in the case of a large outer internal table, can produce considerable memory requirements for little or no work data.