Ansicht
Dokumentation

ABENADMIN_COSTS_DYN_MEM_OBJ_GUIDL - ADMIN COSTS DYN MEM OBJ GUIDL

rdisp/max_wprun_time - Maximum work process run time   ROGBILLS - Synchronize billing plans  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Verwaltungskosten dynamischer Speicherobjekte

Die Flexibilität, die von dynamischen Speicherobjekten geboten wird, gibt es leider nicht völlig kostenlos. Für die Verwaltung dieser Objekte fallen interne Kosten an, die sich in einem zusätzlichen Speicherverbrauch niederschlagen und im ungünstigsten Fall Ursache von zu hohem Speicherverbrauch sein können.

Der gesamte Speicherbedarf eines dynamischen Speicherobjekts setzt sich aus dem Bedarf für die eigentlichen Objekte und dem für die Verwaltungsdaten zusammen. Die Verwaltungsdaten bestehen aus der Referenz mit einer festen Größe von 8 Bytes und einem sogenannten Header, der die Adresse der eigentlichen Daten und zusätzliche Verwaltungsinformationen enthält. Die Referenz verweist erst einmal auf einen Header und nicht direkt auf das Objekt. Die Größe des Headers ist selbst dynamisch und hängt wie folgt von der Art des Speicherobjekts ab:

• String-Header von Strings, deren Länge kleiner als ca. 30 Zeichen bzw. 60 Bytes ist, belegen in Abhängigkeit von der Stringlänge zwischen ca. 10 und 40 Bytes. Für längere Strings belegt der Header unabhängig von der String- Länge ca. 50 Bytes.

• Tabellen-Header belegen ca. 150 Bytes (32-Bit-Architektur) oder ca. 200 Bytes (64-Bit-Architektur).

• Objekt-Header von anonymen Datenobjekten und Instanzen von Klassen belegen unabhängig vom Objekt ca. 30 Bytes.

Die Header werden angelegt, wenn dynamische Datenobjekte mit Inhalt versorgt bzw. Objekte erzeugt werden. Bei der Initialisierung eines dynamischen Datenobjektes (String oder interne Tabelle) wird nur der eigentliche Inhalt gelöscht, und der Header bleibt zur Wiederverwendung bestehen. Nur die Anweisung FREE löscht teilweise auch zu große Tabellen-Header. Beim Löschen eines Objektes durch den Garbage Collector wird auch der Objekt-Header gelöscht.

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 Tabellenheader 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:

• im Mittel 6 Byte pro Tabellenzeile für den Primärindex

• im Mittel 18 Byte pro Tabellenzeile für die Hash-Verwaltung, solange nicht mit einer der Anweisungen DELETE oder SORT auf die Tabelle zugegriffen wird. Nach einem solchen Zugriff werden im Mittel 30 Byte pro Tabellenzeile benötigt

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.

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.

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 besetzte komplexe Datenobjekte

Ein solches Datenobjekt enthält viele tiefe Komponenten, von denen die meisten initial sind.

• Duplikativ besetzte komplexe Datenobjekte

Ein solches Datenobjekt enthält viele tiefe Komponenten, von denen die meisten als Referenzvariablen oder über Sharing auf die gleichen Nutzdaten verweisen.

• Gering besetzte komplexe Datenobjekte

Ein solches Datenobjekt enthält viele tiefe Komponenten, die auf unterschiedliche Objekte, Strings oder interne Tabellen verweisen, die aber nur sehr wenige Nutzdaten enthalten oder leer sind.

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..

Hinweis

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 ausführbares Beispiel DEMO_MEMORY_USAGE demonstriert die Verwaltungskosten tiefer Komponenten mit geringem Dateninhalt.

General Data in Customer Master   ROGBILLS - Synchronize billing plans  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 7869 Date: 20240523 Time: 183004     sap01-206 ( 153 ms )