Memory Requirements of Deep Data Types
All data types that actually contain work data as the contents of their data objects are referred to as "flat" in ABAP. Therefore, all elementary data types of a fixed length are flat. By contrast, data types that contain references as the contents of their data objects which in turn point to work data in another memory area, are called "deep".
Besides data and object references, strings and internal tables also count among the deep data types since they are represented internally also by means of
references. Even structures with multiple nesting are only considered deep if they have at least one deep component.
Generally, the following is true for data types that are created and managed dynamically:
a. Deep data types with a thin fill level, that is, data types with many initial references, are efficiently managed in ABAP as regards their memory requirements. A reference in initial state requires only 8 bytes of memory.
b. Deep data types with a duplicative fill level, that is, data types with many references that are identical or have the same value, are also efficiently handled in ABAP as regards their memory requirements because objects and data
objects are governed by a reference-based semantics. But also with internal tables and strings to which a value-based semantics applies, a sharing logic does not start the copying process until a table involved in the sharing procedure is changed - according to COPY ON WRITE based on reference counting.
c. Deep data types with a minimal fill level, that is, data types containing many references to instances with a small amount of work data, are not handled very efficiently in ABAP as regards their memory requirements. This is the case if the instances are not involved in the sharing procedure since the initial
requirements for referenced instances are considerable.
This means that you can use deep data types with a thin, duplicative and moderate minimal fill level without restrictions in ABAP.
In case of deep data types with a minimal fill level and a low sharing rate, you must consider the initial requirements. Unlike other programming languages, ABAP is not suitable for large-scale use of these data types. As an alternative, you can use a class wrapper since objects have the lowest initial requirements.
The following sections indicate the memory requirements of deep data types in their initial state and after the first assignment:
Internal Tables
Starting with Release 4.6, table headers no longer exist in the memory area that can be addressed by a user. Only a table reference that uses 8 bytes is retained in this area. From Release 4.6 onwards, empty internal tables therefore only occupy 8 bytes of memory irrespective of whether the table is initial or was reset using FREE.
When an internal table contains at least one line or when a previously filled table is reset using only CLEAR and REFRESH, the following memory requirements apply:
Release Architecture Requirements
6.10 32-bit 132 bytes
6.10 64-bit 200 bytes
4.6 32-bit 168 bytes
4.6 64-bit 256 bytes
From Release 6.10 onwards, a sharing logic ensures that the table contents are initially not copied during assignments despite their value-based semantics. The copying process is only initiated if a table involved in the sharing procedure is changed. The memory space gained is considerable. Also, the initial memory requirements are limited to 72 bytes for 32-bit architectures and to 96 bytes for 64-bit architectures.
Objects
Being class instances that are created dynamically, objects are always addressed through a reference. Like an internal table, an initial object therefore uses only 8 bytes of memory. When the object is actually instantiated using CREATE OBJECT, the initial requirements are increased to 36 bytes for 32-bit architectures and to 64 bytes for 64-bit architectures.
Data Objects
Being data type instances that are created dynamically, data objects are also addressed through a reference. Like table and object references, they only use 8 bytes of memory if in initial state. When a data object is actually instantiated using CREATE DATA, the initial requirements are increased to 80 bytes for 32-bit architectures and to 100 bytes for 64-bit architectures.
Strings
Strings of the type STRING or XSTRING are also addressed through references, using 8 bytes of memory initially. When a string is filled, the initial requirements are increased to 48 bytes for 32-bit architectures and to 72 bytes for 64-bit
architectures.
As with internal tables, the sharing logic of strings considerably reduces the memory required. The initial requirements for strings involved in the sharing procedure is the same as for initial strings: only 8 bytes.
Display of the Memory Required
In order to check the memory required by a program, you can display memory usage hit lists in the ABAP Debugger by choosing Goto → System → System areas. These lists are available for the following areas:
Area Hit list
ITAB-TOP25 Maximum of 25 internal tables, sorted in ascending order by memory required
OBJ-TOP25 Maximum of 25 objects, sorted in ascending order by memory required
REF-TOP25 Maximum of 25 data references, sorted in ascending order by memory required
ALL-TOP25 The 25 program components with the highest memory requirements
You can also choose Settings → Memory Display On/Off from the menu to display the required memory referenced and actually used by a specific component.
References
References in ABAP
A reference is a pointer to an instance, and is contained in a reference variable. A reference variable is a data object, whose type you specify using the REF TO addition in the TYPES or DATA statement.
There are various types of reference variables. The type specifies the instances to which the reference can point. The following reference types are currently
supported:
References --+-- Data references
|
+-- Object references --+-- Class references +-- Interface references
The main distinction is between data and object references.
• A data reference can point to any data object. You specify its type using the additions TYPE REF TO DATA or TYPE REF TO type to the TYPES and DATA statements . With the CREATE DATA statement you can use data references to create data objects dynamically. You can write references to existing data objects in to reference variables using the GET
REFERENCE statement.
In order to access the field that a data reference points to, you use the dereferencing operator ->*. If the data reference is completely typed, that is it has no generic type, you can insert the expression dref->* at any operand position. For all data reference variables you can use ASSIGN dref->* TO
<fs> assign the field that a data reference indicates to a field symbol . The statements and techniques discussed above are only suitable for working with generic data references. You can also assign a type and, as a result, directly address data references.
• Object references can point to objects in ABAP Objects. An object reference can be a class reference or an interface reference:
o Class references allow you to access all of the components of a class.
You specify their type using the TYPE REF TO class addition in the TYPES or DATA statement. You can use class references in the CREATE OBJECT statement to create dynamic data objects.
o Interface references allow you static access to the corresponding interface components of a class. You specify their type using the addition TYPE REF TO ifac in the TYPES or DATA statement. You can also use interface references in the CREATE OBJECT statement with the TYPE addition to create dynamic data objects.
You can check the content of reference variables using the logical expression DS:ABEN.LOGEXP_BOUND> ref IS BOUND. It is true, when a reference variable indicates a valid object.