<?xml version="1.0" encoding="utf-8"?>
<page xmlns="http://projectmallard.org/1.0/" type="guide" style="task" id="massif" xml:lang="de">
    <info>
      <link type="guide" xref="index#massif"/>
    
    <mal:credit xmlns:mal="http://projectmallard.org/1.0/" type="translator copyright">
      <mal:name>Mario Blättermann</mal:name>
      <mal:email>mario.blaettermann@gmail.com</mal:email>
      <mal:years>2009, 2012, 2013, 2015</mal:years>
    </mal:credit>
  
    <mal:credit xmlns:mal="http://projectmallard.org/1.0/" type="translator copyright">
      <mal:name>Christian Kirbach</mal:name>
      <mal:email>christian.kirbach@googlemail.com</mal:email>
      <mal:years>2010</mal:years>
    </mal:credit>
  </info>
      <title>Verwendung von <app>Massif</app> zur Profilierung des Speicherverbrauchs in GNOME-Software</title>

    <p>Dieser Artikel beschreibt, wie Sie den Heap-Profiler <app>Massif</app> mit GNOME-Anwendungen verwenden. Wir beschreiben den Aufruf, die Interpretation und die Möglichkeiten, die Ausgaben von <app>Massif</app> richtig zu nutzen. Das Spiel <app>Swell Foop</app> wird als Beispiel verwendet.</p>
   <section id="optimization-massif-TBL-intro">
        <title>Einführung</title>
        <p><app>Massif</app> ist Teil der Programmsammlung <link href="http://valgrind.org/">valgrind</link>, die Werkzeuge zur Speicherprofilierung bereitstellt. Zweck ist die Erstellung eines detaillierten Überblicks über die dynamische Speichernutzung während der Lebensdauer eines Programms. Speziell wird der Speicherverbrauch von »heap« und »stack« aufgezeichnet.</p>
        <p>Der Heap ist der Speicherbereich, der von Funktionen wie »malloc« belegt wird. Er wächst bei Bedarf und ist gewöhnlich der größte Speicherbereich eines Programms. Der Stapelspeicher (Stack) dient zur Speicherung der lokalen Daten von Funktionen. Dies schließt »automatische« Variablen in C und die Rückgabeadresse von Subroutinen ein. Der Stapelspeicher ist typischerweise wesentlich kleiner und deutlich aktiver als der Heap. Wir werden den Stapelspeicher nicht gesondert betrachten, weil ihn <app>Massif</app> wie einen weiteren Teil des Heap ansieht. <app>Massif</app> liefert auch Informationen darüber, wie viel Arbeitsspeicher für den Heap belegt wird.</p>
        <p><app>Massif</app> erstellt zwei Ausgabdateien: eine grafische Übersicht in einer PostScript-Datei und eine detaillierte Ausgabe in einer Textdatei.</p>
    </section>
    <section id="optimization-massif-TBL-using-massif">
        <title><app>Massif</app> mit GNOME verwenden</title>
        <p><app>Massif</app> hat sehr wenige Optionen und für viele Programme brauchen Sie diese auch gar nicht. Für GNOME-Anwendungen jedoch muss die Anzahl der Abstiegsebenen des Aufruf-Stapelspeichers erhöht werden, weil sie bei diesen Speicheranforderungen tief in glib oder GTK+ verborgen liegen. Dies wird mit dem Parameter »--depth« erreicht. Die Voreinstellung ist 3; eine Erhöhung auf 5 stellt sicher, dass der Aufruf-Stapelspeicher bis zu Ihrem Code reicht. Ein oder zwei weitere Ebenen können auch wünschenswert sein, um weiteren Kontext zu ersehen. Weil die Detailangaben sehr schnell erdrückend werden können ist es am besten, mit dem kleineren Parameter zu beginnen und ihn nur bei Bedarf zu erhöhen.</p>
        <p>Es ist auch nützlich, <app>Massif</app> mitzuteilen, welche Funktionen in glib Arbeitsspeicher anfordern. So wird eine unnötige Ebene Funktionsaufrufe aus den Berichten entfernt und verbessert den Einblick, welcher Code Speicher anfordert. Speicher anfordernde Funktionen in glib sind: g_malloc, g_malloc0, g_realloc, g_try_malloc und g_mem_chunk_alloc. Verwenden Sie die Option »--alloc-fn«, um Massif diese Namen mitzuteilen.</p>
        <p>Ihre Befehlszeile sollte daher so aussehen:</p>
        <code>
valgrind --tool=massif --depth=5  --alloc-fn=g_malloc --alloc-fn=g_realloc --alloc-fn=g_try_malloc \
         --alloc-fn=g_malloc0 --alloc-fn=g_mem_chunk_alloc swell-foop
        </code>
        <p>Das Programm <app>Swell Foop</app> werden wir als Beispiel verwenden. Seien Sie gewarnt: <app>Valgrind</app> emuliert den Prozessor, wodurch es <em>äußerst</em> langsam läuft. Außerdem wird sehr viel Speicher benötigt.</p>
    </section>
    <section id="optimization-massif-TBL-interpreting-results">
        <title>Interpretieren der Ergebnisse</title>
        <p>Die grafische Ausgabe von <app>Massif</app> ist weitgehend selbsterklärend. Jedes Band stellt den einer Funktion zugewiesenen Speicher nach Zeit dar. Sobald Sie herausgefunden haben, welche Bänder den meisten Speicher verbrauchen, üblicherweise die dickeren, oberen, dann schauen Sie sich die Textausgabe für weitere Details an.</p>
        <p>Die Textdatei ist hierarchisch in Abschnitte gegliedert. Am oberen Ende finden sich die größten Speicherverbraucher, in absteigender Ordnung nach Speicherzeit. Darunter finden sich weitere Abschnitte, die je nach dem Platz im Aufruf-Stack feiner detaillierter sind. Um dies zu verdeutlichen, verwenden wir die Ausgabe des oben stehenden Befehls.</p>
        <figure>
            <title><app>Massif</app>-Ausgabe für die nicht optimierte Version des Programms <app>Swell Foop</app>.</title>
            <media type="image" src="figures/massif-before.png"/>
         </figure>
        <p>Das Bild oben zeigt eine typische PostScript-Ausgabe von <app>Massif</app>. Dies ist das Ergebnis, wenn Sie eine einzige Runde <app>Swell Foop</app> (Version 2.8.0) spielen und dann die Anwendung schließen. Die PostScript-Datei hat einen Namen ähnlich wie <file>massif.12345.ps</file> und die Text-Datei <file>massif.12345.txt</file>. Die Zahl im Dateinamen entspricht der Prozesskennung des untersuchten Programms. Wenn Sie dieses Beispiel nachstellen, so werden Sie zwei Versionen jeder Datei mit leicht verschiedenen Nummern finden. Dies liegt daran, dass <app>Swell Foop</app> einen zweiten Prozess startet und <app>Massif</app> diesen ebenfalls protokolliert. Wie werden diesen zweiten Prozess ignorieren. Er verbraucht nur sehr wenig Speicher.</p>
        <p>Oben in der Grafik sehen Sie ein großes gelbes Band mit der Bezeichnung gdk_pixbuf_new. Dies schaut nach einem idealen Kandidaten für Optimierungsversuche aus, aber wir werden die Textdatei verwenden müssen, um herauszufinden, wo gdk_pixbuf_new aufgerufen wird. Der Anfang der Textdatei sieht in etwa so aus:</p>
        <code>
Command: ./swell-foop

== 0 ===========================
Heap allocation functions accounted for 90.4% of measured spacetime

Called from:
  28.8% : 0x6BF83A: gdk_pixbuf_new (in /usr/lib/libgdk_pixbuf-2.0.so.0.400.9)

    6.1% : 0x5A32A5: g_strdup (in /usr/lib/libglib-2.0.so.0.400.6)

    5.9% : 0x510B3C: (within /usr/lib/libfreetype.so.6.3.7)

    3.5% : 0x2A4A6B: __gconv_open (in /lib/tls/libc-2.3.3.so)
        </code>
        <p>Die Zeile mit »=«-Zeichen deutet an, wie tief wir uns in der Stack-Trace befinden. In diesem Fall sind wir ganz oben. Danach werden die größten Speicherbeleger nach absteigender Raumzeit aufgeführt. Raumzeit ist das Produkt der Menge des belegten Speichers und wie lange er belegt wurde. Dies entspricht der Fläche der Bänder im Grafen. Dieser Teil der Datei belegt, was wir bereits wissen: der Großteil der Raumzeit ist gdk_pixbuf_new gewidmet. Um herauszufinden, was gdk_pixbuf_new aufrief, müssen wir weiter unten in der Textdatei suchen:</p>
        <code>
== 4 ===========================
Context accounted for 28.8% of measured spacetime
  0x6BF83A: gdk_pixbuf_new (in /usr/lib/libgdk_pixbuf-2.0.so.0.400.9)
  0x3A998998: (within /usr/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-png.so)
  0x6C2760: (within /usr/lib/libgdk_pixbuf-2.0.so.0.400.9)
  0x6C285E: gdk_pixbuf_new_from_file (in /usr/lib/libgdk_pixbuf-2.0.so.0.400.9)

Called from:
  27.8% : 0x804C1A3: load_scenario (swell-foop.c:463)

    0.9% : 0x3E8095E: (within /usr/lib/libgnomeui-2.so.0.792.0)

  and 1 other insignificant place
        </code>
        <p>Die erste Zeile besagt, dass wir uns nun vier Ebenen tief im Stapelspeicher befinden. Darunter ist eine Auflistung der Funktionsaufrufe, die von hier bis  gdk_pixbuf_new reichen. Schließlich findet sich eine Liste von Funktionen, die sich eine Ebene darunter befinden und jene Funktionen aufrufen. es gibt natürlich auch Einträge für die Ebenen 1 bis 3, aber dies ist die erste Ebene, die man über den GDK-Code bis zum <app>Swell Foop</app>-Code erreichen kann. Aus der Auflistung kann man sofort erkennen, dass der problematische Code in load_scenario ist.</p>
        <p>Jetzt, wo wir wissen, welcher Teil unseres Codes alle Raumzeit belegt, können wir ihn betrachten und die Ursache herausfinden. Es stellt sich heraus, dass load_scenario einen Pixbuf aus einer Datei lädt und diesen Speicher nie mehr frei gibt. Nachdem das Problem identifiziert wurde, können wir es beheben.</p>
    </section>
    <section id="optimization-massif-TBL-acting-on-results">
        <title>Aufgrund der Ergebnisse handeln</title>
        <p>Ein Reduzieren des Verbrauches an Raumzeit ist gut, aber es gibt zwei verschiedene Wege, dies zu tun. Sie können entweder die angeforderte Speichermenge oder die Belegungszeit reduzieren. Betrachten Sie für einen Moment ein Modellsystem mit nur zwei laufenden Prozessen. Beide Prozesse belegen fast allen physikalischen Arbeitsspeicher und sobald sie sich überlappen, wird das System auslagern müssen und es wird sehr langsam. Es ist offensichtlich, dass die beiden Prozesse friedlich nebeneinander existieren können, wenn wir den Speicherverbrauch jedes Prozesses halbieren. Wenn wir statt dessen die Speicherbelegungszeit halbieren, dann können die beiden Prozesse nebeneinander existieren, aber nur solange ihre Zeiträume hoher Speicherbelegung nicht überlappen. Demnach ist es besser, die Speicherbelegung zu reduzieren.</p>
        <p>Unglücklicherweise schränken die Erfordernisse des Programms die Wahl der Optimierung ein. Die Größe der Pixbuf-Daten in <app>Swell Foop</app> ist von der Größe der Grafiken im Spiel abhängig und kann nicht ohne Weiteres reduziert werden. Allerdings kann die Zeit zum Laden des Programms in den Speicher drastisch reduziert werden! Das Bild unten zeigt die <app>Massif</app>-Analyse von <app>Swell Foop</app> nach den Änderungen, die die Pixbufs entsorgen, sobald diese vom X-Server geladen wurden.</p>
        <figure>
            <title><app>Massif</app>-Ausgaben für das optimierte Programm <app>Swell Foop</app>.</title>
           <media type="image" src="figures/massif-after.png"/>
            </figure>
        <p>Die Raumzeit-Belegung von gdk_pixbuf_new ist nun nur noch ein dünnes Band, das nur kurzzeitig einen Spitzenwert hat (es ist nun das sechzehnte schraffierte magenta Band von oben). Als Bonus ist der Spitzenspeicherverbrauch um 200 kB gesunken, weil die Spitze vor anderen Speicheranforderungen liegt. Wenn zwei solche Prozesse zeitgleich liefen, wäre die Wahrscheinlichkeit ziemlich gering, dass der höchste Speicherverbrauch beider zusammen fällt.</p>
        <p>Können wir noch zulegen? Eine schnelle Untersuchung der Textausgabe von <app>Massif</app> enthüllt: g_strdup ist der neue Hauptschuldige.</p>
        <code>
Command: ./swell-foop

== 0 ===========================
Heap allocation functions accounted for 87.6% of measured spacetime

Called from:
    7.7% : 0x5A32A5: g_strdup (in /usr/lib/libglib-2.0.so.0.400.6)

    7.6% : 0x43BC9F: (within /usr/lib/libgdk-x11-2.0.so.0.400.9)

    6.9% : 0x510B3C: (within /usr/lib/libfreetype.so.6.3.7)

    5.2% : 0x2A4A6B: __gconv_open (in /lib/tls/libc-2.3.3.so)
        </code>
        <p>Bei näherer Betrachtung sehen wir jedoch, dass es von vielen verschiedenen Orten aus aufgerufen wird.</p>
        <code>
== 1 ===========================
Context accounted for  7.7% of measured spacetime
  0x5A32A5: g_strdup (in /usr/lib/libglib-2.0.so.0.400.6)

Called from:
    1.8% : 0x8BF606: gtk_icon_source_copy (in /usr/lib/libgtk-x11-2.0.so.0.400.9)

    1.1% : 0x67AF6B: g_param_spec_internal (in /usr/lib/libgobject-2.0.so.0.400.6)

    0.9% : 0x91FCFC: (within /usr/lib/libgtk-x11-2.0.so.0.400.9)

    0.8% : 0x57EEBF: g_quark_from_string (in /usr/lib/libglib-2.0.so.0.400.6)

  and 155 other insignificant places
        </code>
        <p>Nun begegnen wir geschmälerten Resultaten für unsere Bemühungen. Der Graph deutet einen weiteren möglichen Schritt an: Die Bänder »other« und »heap admin« sind beide ziemlich groß. Dies besagt, dass eine Vielzahl kleiner Anforderungen an vielen Orten gemacht werden. Jene zu eliminieren ist schwierig, aber wenn sie zusammen gelegt werden, dann werden die einzelnen Anforderungen größer und der Verwaltungsaufwand (»heap admin«) kann reduziert werden.</p>
    </section>
    <section id="optimization-massif-TBL-caveats">
        <title>Vorbehalte</title>
        <p>Es gibt ein paar Dinge, auf die man achten muss. Erstens: Raumzeit wird nur als Prozentangabe geliefert. Sie müssen mit der Gesamtgröße des Programms vergleichen, um festzustellen, ob es sich lohnt, diese Speichermenge anzugehen. Der Graph mit der vertikalen Achse in Kilobytes eignet sich gut dafür.</p>
        <p>Zweitens: <app>Massif</app> erfasst nur die Speicherbelegung durch Ihr eigenes Programm. Ressourcen wie Pixmaps werden im X-Server gespeichert und werden nicht durch <app>Massif</app> berücksichtigt. In dem Beispiel mit <app>Swell Foop</app> haben wir tatsächlich nur den Speicherverbrauch von client-seitigen Pixbufs zu server-seitigen Pixmaps verlagert. Obwohl dies nur nach Schummeln aussieht, gab es dennoch Geschwindigkeitsgewinne. Bilddaten im X-Server beschleunigen die Grafik-Routinen und verhindert viele Inter-Prozess-Kommunikation. Ebenso werden die Pixmaps in nativem Grafikformat gespeichert, welches oft kompakter ist als das 32-bit RGBA-Format von gdk_pixbuf. Um den Effekt von Pixmaps und anderen Ressourcen des X-Servers zu messen, sollten Sie das Programm <link href="http://www.freedesktop.org/Software/xrestop">xrestop</link> verwenden.</p>
    </section>
</page>