ARTICLE
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:
Complex data objects with a sparse fill level
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 .
Complex data objects with a duplicative fill level
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 .
Complex data objects with a low fill level
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.
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 t
able-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.
See Deep Data Objects, Memory Usage .
Documentation extract taken from SAP system, � Copyright SAP AG. All rights reserved