GUIDELINE 6.50
Administration Costs of Dynamic Memory Objects
ABAP_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:
String header s of strings whose length is less than
approximately 30 characters or 60 bytes require between 10 and 40 bytes
approximately, depending on the string length. For longer strings, the
header requires approximately 50 bytes, regardless of the string
length.
Table headers require approximately 150 bytes (in 32 bit
architecture) or approximately 200 bytes (in 64 bit architecture).
Object header s of anonymous data objects and instances of
classes require approximately 30 bytes, regardless of the object.
The header s 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:
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 .
ABAP_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.
ABAP_DETAILS
Obwohl die Speicherverwaltung dynamischer Speicherobjekte f�r den
Entwickler weitestgehend unsichtbar ist und sich seiner direkten K
ontrolle 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..
Latest notes:
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.
Documentation extract taken from SAP system, � Copyright SAP AG. All rights reserved