Arbeiten mit den Ranglisten in Memory Inspector 
Vorgehensweise
Funktion der Rangliste
Wie der Dominatorbaum zeigt die Sicht Rangliste eine Liste der dynamischen Speicherobjekte in Ihrem Programm nach Größe geordnet an. Außerdem sind Querverweise auf dynamische Speicherobjekte und die Referenzen auf diese Objekte enthalten.
Die Besonderheit der Rangliste liegt im Vergleich von Speicherabzügen. Im Dominatorbaum ist es nicht möglich, ältere und neuere Speicherabzüge miteinander zu vergleichen.
Durch den Vergleich von Speicherabzügen in der Rangliste können Sie schnell erkennen, wo Änderungen im Speicherverbrauch dynamischer Speicherobjekte zwischen dem älteren und dem neueren Abzug aufgetreten sind.
Speicherabzug (T_1 — T_0): Vergleich von Speicherabzügen in der Rangliste
Ein Abzugsvergleich zeigt nur die Änderungen im Speicherverbrauch auf:
Neue Objekte und neuer für vorhandene Objekte allokierter Speicher werden rot mit einem +-Zeichen dargestellt.
Gelöschte Objekte und freigegebener Speicher in vorhandenen Objekten werden blau mit einem —-Zeichen dargestellt.
Neue, vorhandene und gelöschte Objekte werden getrennt nach Größe aufgelistet. Beispielsweise sehen Sie getrennte Rangfolgen von 1 bis n für die größten neuen Speicherobjekte, für den größten Anstieg bei vorhandenen Objekten, für die größte Abnahme bei vorhandenenen Objekten sowie für die größten gelöschten Objekte. Außerdem gilt der Grenzwert für die Listenelemente für jede einzelne Kategorie getrennt.
Hinweis
Anders als der Dominatorbaum listet die Rangliste alle Speicherobjekte auf nur einer Ebene auf, ohne Abbildung der Enthaltenseinbeziehungen zwischen den Objekten und ihrer Relationen im Hinblick auf den gebundenen Speicher. Verwenden Sie den Dominatorbaum, wenn Sie die Objektrelationen im Hinblick auf den gebundenen Speicher ansehen möchten.
Auswertung von Speicherabzugsvergleichen in der Rangliste
Ihre Analyse baut auf den im Speicherabzugsvergleich verwendeten Farben auf. Rot zeigt an, wo neuer Speicher allokiert wurde. Blau zeigt an, wo Speicher freigegeben wurde.
In der Regel ist es problemlos erkennbar, aus welchem Grund neue Speicherobjekte angelegt wurden - im Programmquelltext sehen Sie, an welcher Stelle diese Objekte entstanden sind.
In einigen Fällen ist es nicht sofort verständlich, warum Speicher für vorhandene Objekte hinzugefügt wurde. Vor allem bei Wertesemantikobjekten - internen Tabellen, Strings und Boxed Components - ist eine Rückverfolgung der Referenzen auf die Objekte hilfreich, um festzustellen, warum und an welcher Stelle im Quelltext neue Kopien dieser Objekte im Speicher angelegt wurden. Verwenden Sie die Einzelabzugsanzeigen in der Rangliste oder im Dominatorbaum, um Änderungen bei den Referenzen nachzuvollziehen.
Beim oben abgebildeten Vergleich von Speicherabzügen:
Wurden mehrere neue Speicherobjekte hinzugefügt. Nur eines dieser Objekte, INSTANCE_TABLE, ist für den Anwendungsprogrammierer interessant. Die anderen neuen Objekte wurden durch die ABAP-Infrastruktur zur Verwaltung interner Tabellen angelegt.
Wurde zwei internen Tabellen, die bereits im ersten Speicherabzug vorhanden waren, weiterer Speicher zugewiesen, der in der Spalte Gebunden (allokiert) rot angezeigt wird.
Die Einzelreferenz auf jede Tabelle und die unterschiedliche Anzahl an Einträgen in den Tabellen (7385 Einträge in LT_SYSTEM_TABLE und 7384 Einträge in SYSTEM_TABLE) sind deutliche Hinweise darauf, warum neuer Speicher allokiert wurde. Im älteren Speicherabzug zeigten die Tabellenreferenzvariablen wahrscheinlich auf einen gemeinsam genutzten Tabellenkörper im Speicher. Neue Einträge, die mittels dieser Tabellenreferenzvariablen hinzugefügt wurden, erzwangen in ABAP das Anlegen einer neuen eigenen Kopie der gemeinsam genutzten Tabelle für jede Variable. (Siehe Wertesemantik im Abschnitt Konzepte.)
Um diesen Hinweisen nachzugehen, wechseln Sie zu t_0 (erster Abzug) und zeigen den Dominatorbaum oder die Rangliste an. Hier sehen Sie die Liste der Referenzen auf das ursprüngliche gemeinsam genutzte Speicherobjekt. Im ersten Abzug hatte die betroffene Tabelle 7383 Einträge und wurde von LT_SYSTEM_TABLE und SYSTEM_TABLE im Klassenobjekt C2 (sowie weiteren Tabellenreferenzvariablen) gemeinsam genutzt.
Analyse von Speicheränderungen durch Nachverfolgung von Referenzen auf Speicherobjekte
Die Vergleichssicht (oben) zeigt, dass zu den internen Tabellenkörpern, die von LT_SYSTEM_TABLE und SYSTEM_TABLE in der Instanz der Klasse C2 referenziert wurden, neue Einträge hinzugefügt wurden. Die angezeigte Anzahl der Einträge stieg von 7383 im ursprünglichen Tabellenobjekt im Speicher auf 7384 bzw. 7385 an. Gemäß der Wertesemantik hat die ABAP-Infrastruktur als Reaktion darauf eigene Kopien jeder Tabelle im Speicher bereitgestellt.
Funktion der Typen-Rangliste
Wie die Rangliste sortiert die Typen-Rangliste alle Speicherobjekte im internen Modus nach Größe, um die wichtigsten Speicherverbraucher darzustellen.
Anders als die Rangliste jedoch aggregiert die Typen-Rangliste den Speicherverbrauch nach Objekttyp. In dieser Sicht wird der Speicherverbrauch nur für Referenzsemantikobjekte aggregiert - also Klassenobjekte und anonyme Datenobjekte.
Die Typen-Rangliste ist besonders nützlich, wenn Sie einschätzen möchten, wie sich kleinere Klassen- oder Datenobjekte auf den Speicherverbrauch auswirken und welchen Einfluss die einzelnen im Programm verwendeten Objekttypen haben.
Ein schlecht designtes ABAP-Objects-Programm behält unter Umständen Tausende von Instanzen einer ABAP-Klasse für die gesamte Dauer der Laufzeit. Obwohl die einzelnen Objekte recht klein sein können, kann ihr aggregierter Speicherverbrauch dennoch beträchtlich sein. Die einzelnen Objekte erscheinen in keinem Fall an erster Stelle in den Rangfolgen im Dominatorbaum oder in der Rangliste. In der Typen-Rangliste jedoch erkennen Sie sofort, wie sich diese Objekte auf den Speicherverbrauch auswirken.
Wie die Rangliste eignet sich die Typen-Rangliste sehr gut für den Vergleich von Speicherabzügen. In diesem Beispiel können Sie sehen, dass eine Reihe von Objekten vom ABAP-Klassentyp C1 angelegt wurde. Die neuen Instanzen werden als erhöhter Speicher aggregiert, der für die Klasse C1 allokiert wurde Die Objekte von Klasse C1 verbrauchen insgesamt etwa 235 KB Speicher. 123 KB dieser Speichermenge geht auf die neuen Instanzen zurück, die zwischen den beiden Speicherabzügen hinzugefügt wurden.
Aggregierter Objektspeicher in der Typen-Rangliste
Im Beispiel können Sie sehen, dass auch mehrere interne Tabellen hinzugefügt wurden. Wertesemantikobjekte - interne Tabellen, Strings und Boxed Components - werden in der Typen-Rangliste jedoch nicht aggregiert. Daher wird jede interne Tabelle INSTANCE_TABLE als unabhängiges Speicherobjekt der obersten Ebene aufgelistet - obwohl sie durch die neuen Klasseninstanzen gebunden ist.