Kontakt

Ansicht
Dokumentation

ABENMEMORY_CONSUMPTION_1 - MEMORY CONSUMPTION 1

ABENMEMORY_CONSUMPTION_1 - MEMORY CONSUMPTION 1

ABAP Short Reference   Addresses (Business Address Services)  
Diese Dokumentation steht unter dem Copyright der SAP AG.
SAP E-Book

Speicherbedarf tiefer Datenobjekte

Der Speicherbedarf eines tiefen Datenobjekts setzt sich aus einem konstanten Speicherbedarf für die Referenz und einem dynamischen Speicherbedarf für den so genannten Header und die eigentlichen Objekte zusammen.

  • Der Speicherbedarf für die Referenz beträgt 8 Byte. Bei Daten- und Objektreferenzen ist dies der Speicherbedarf der explizit deklarierten Referenzvariable. Bei Strings, internen Tabellen und Boxed Components wird intern eine implizite Referenz angelegt. Solange kein dynamischer Speicher angefordert wird, beträgt der Speicherbedarf für einen String, eine interne Tabelle oder eine Boxed Component genau 8 Byte.
  • Der dynamische Speicher setzt sich aus einem Header (Stringheader, Tabellenheader, Boxheader oder Objektheader) und den eigentlichen Daten (String, Tabellenkörper, Unterstruktur, anonymes Datenobjekt bzw. Instanz einer Klasse) zusammen. Die Referenz verweist auf den Header, der wiederum die Adresse der eigentlichen Daten und zusätzliche Verwaltungsinformationen enthält. Die folgende Abbildung veranschaulicht die Speicherbelegung tiefer Datenobjekte.

IMAGE @@ABDOC_Deep_Memory.gif@@567@@245@@

Dynamischer Speicher (Header und Daten) wird angefordert

  • bei dynamischen Datenobjekten (Strings und interne Tabellen) durch das Einfügen von Inhalten. Bei internen Tabellen wird der Speicher blockweise angefordert, wobei die initiale Größe eines Blocks durch den Zusatz INITIAL SIZE bei der Definition einer internen Tabelle beeinflusst werden kann.

Wenn ein tiefes Datenobjekt mit CLEAR, REFRESH (obsolet) oder FREE initialisiert wird, werden die eigentlichen Daten gelöscht, die Referenzvariablen und bei dynamischen Datenobjekten auch der Header bleiben aber vorhanden. Letzteres wird wiederverwendet, wenn eine andere Speicheranforderung gemacht wird. Dadurch besteht der Speicherbedarf eines einmal verwendeten und danach gelöschten dynamischen Datenobjekts außer bei Boxed Components aus der Referenz und dem Speicherbedarfs des Headers. Nur bei Anwendung der Anweisung FREE auf interne Tabellen werden unter Umständen auch Tabellenheader gelöscht, wenn durch diese zu viel Speicher belegt würde. Bei statischen Boxen führt das Initialisieren derzeit noch nicht zu Freigabe von Speicher. Die Initialisierung einer statischen Box, bei der das Initialwert-Sharing aufgehoben ist, löscht nicht die Instanz in der internen Sitzung sondern weist ihr ihren typabhängigen Initialwert zu.

Der Speicherbedarf der verschiedenen Header bewegt sich etwa in folgenden Größenordnungen:

  • Die Speicherbelegung eines Stringheaders hängt aus Performancegründen von der Länge des Strings ab. Strings, deren Länge kleiner als ca. 30 Zeichen bzw. 60 Bytes ist, bezeichnen wir als kurze Strings. Der Speicher-Overhead der Stringheader von kurzen Strings beträgt in Abhängigkeit von der Stringlänge zwischen ca. 10 und ca. 40 Bytes. Für alle übrigen Strings beträgt der Overhead unabhängig von der Stringlänge ca. 50 Bytes.
  • Ein Tabellenheader einer internen Tabelle, für die bereits dynamischer Speicher angefordert wurde, belegt unabhängig von der Zeilenbelegung größenordnungsmäßig ca. 100 Bytes. Bei einer gefüllten internen Tabelle kommen je nachdem, ob es sich um eine Plattform mit 32- oder 64-Bit-Architektur handelt, nochmals ca. 50 bzw. 100 Bytes für Pointer hinzu.
  • Ein Boxheader einer Boxed Component belegt größenordnungsmäßig immer ca. 20 bis 30 Bytes.
  • Ein Objektheader belegt größenordnungsmäßig immer ca. 30 Bytes.

Bei internen Tabellen kommen zu den Verwaltungsdaten im Header weitere zeilenbezogene Verwaltungskosten hinzu. Dieser Speicher wird nicht im Tabellenheader sondern parallel zum Tabellenkörper angelegt. D.h., beim Löschen von Zeilen werden auch die zugehörigen Verwaltungsdaten gelöscht.

Hinweise

  • Das Löschen von Zeilen interner Tabellen mit DELETE gibt in aller Regel keinen Speicher der internen Tabelle frei. Um Speicher interner Tabellen freizugeben, müssen Anweisungen wie CLEAR oder FREE verwendet werden.

Tiefe Datenobjekte, Speicherverbrauch






rdisp/max_wprun_time - Maximum work process run time   PERFORM Short Reference  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 6779 Date: 20240523 Time: 105040     sap01-206 ( 119 ms )