ABAP Keyword Documentation →  ABAP Programming Guidelines →  Robust ABAP →  Dynamic Programming Techniques → 

Administration Costs of Dynamic Memory Objects

Background

Dynamic memory objects provide flexibility, but this comes at a price. The administration of these objects incurs internal costs, which are reflected in increased memory consumption, and in the worst case possibly far too high.

The total memory requirements of a dynamic memory object comprise the requirements of the objects themselves and the requirements of the administration data. The administration data consists of the reference, with a fixed size of 8 bytes, and a header that contains the address of the data itself and additional administration information. The reference initially points to a header and not directly to the object. The size of the header is itself dynamic and depends on the category of memory object as follows:

The headers are created when dynamic data objects are provided with content or when objects are generated. When a dynamic data object (a string or internal table) is initialized, only the content itself is deleted, while the header is retained to be used again. Only the statement FREE deletes (some) table headers that are too big. When it deletes an object, Garbage Collector also deletes the object header.

Bei internen Tabellen kommt zu den Verwaltungsdaten im Header, die weitestgehend unabhängig von der Zeilenzahl sind, ein weiterer Anteil für jede Zeile hinzu, wie die Index- oder Hash-Verwaltung. Dieser Speicher wird nicht im Tabellen-Header, sondern parallel zum Tabellenkörper angelegt. Abhängig von der Tabellenart hat jede Tabelle mindestens einen Primärindex (Standardtabellen, sortierte Tabellen) oder eine Hash-Verwaltung (Hash-Tabellen). Die Kosten sind:

Für jeden zusätzlichen sekundären Tabellenschlüssel erhöht sich der Speicherbedarf zusätzlich um den für die Sekundärschlüsselverwaltung (Sekundärindex oder sekundäre Hash-Verwaltung) benötigten Speicher.

Rule

Verhältnis von Verwaltungs- zu Nutzdaten beachten

Behalten Sie bei der Verwendung dynamisch verwalteter Speicherobjekte im Auge, dass neben dem Speicher für die eigentlichen Daten auch Speicher für Verwaltungszwecke benötigt wird. Dieser administrative Anteil sollte im Vergleich zu den Nutzdaten nicht zu groß werden.

Details

Obwohl die Speicherverwaltung dynamischer Speicherobjekte für den Entwickler weitestgehend unsichtbar ist und sich seiner direkten Kontrolle entzieht, sollten bei Design und Entwicklung die Verwaltungskosten im Auge behalten werden, sodass diese nicht unverhältnismäßig groß gegenüber dem eigentlichen Dateninhalt werden. Bei internen Tabellen setzen sich die Verwaltungsdaten beispielsweise aus einem von der Zeilenanzahl weitgehend unabhängigen Anteil sowie einem Anteil für jede Zeile zusammen. Daher sind sowohl Tabellen mit sehr wenigen als auch Tabellen mit sehr schmalen Zeilen ungünstig. Eine sortierte Tabelle von Integer-Zahlen verbraucht beispielsweise stets mehr Speicher für ihre Verwaltungsinformationen als für die eigentlichen Nutzdaten. Hash-Tabellen haben einen noch höheren Verwaltungsaufwand pro Zeile.

Daneben spielt die sogenannte Besetzung komplexer Datenobjekte eine Rolle. Werden die Nutzdaten in wenigen großen Speicherobjekten abgelegt, fällt der administrative Anteil im Allgemeinen nicht ins Gewicht. Wenn dagegen komplexe Datenobjekte (Strukturen, interne Tabellen) viele tiefe Komponenten haben, ist Vorsicht geboten: Beispielsweise geht bei Tabellen von vielen relativ kleinen Strings oder bei geschachtelten Tabellen, die viele relativ kleine Tabellen enthalten, unverhältnismäßig viel Speicherplatz verloren. Im Wesentlichen sind dabei drei Fälle zu unterscheiden:

Dünn und duplikativ besetzte komplexe Datenobjekte können in der Regel unbedenklich verwendet werden. Bei gering besetzten komplexen Datenobjekten kann sich aber leicht ein Missverhältnis von Verwaltungs- zu Nutzdaten ergeben. Für den massiven Einsatz gering besetzter Datenobjekte ist ABAP nicht geeignet.

Da die Zusatzkosten für Objekte am geringsten sind und da Objekte anders als dynamische Datenobjekte restlos aus dem Speicher gelöscht werden können, kann bei geringem Datenbestand eventuell auch eine Klassenverschalung als Alternative zur direkten Verwendung von internen Tabellen in Betracht gezogen werden. Dies ist eine Ausnahme zur Regel, dass dynamische Datenobjekte in der Regel direkt zu verwenden sind..

Note

Neben dem Verhältnis von Verwaltungs- zu Nutzdaten ist bei internen Tabellen auch das Verhältnis von dem für Nutzdaten allokierten Speicher zum tatsächlich benutzten Speicher interessant.

Beispiel

Ein Beispielprogramm DEMO_MEMORY_USAGE demonstriert die Verwaltungskosten tiefer Komponenten mit geringem Dateninhalt.