Browsing German translation

43.

This article describes how to use the <application>Massif</application> heap profiler with GNOME applications. We describe how to invoke, interpret, and act on the output of <application>Massif</application>. The <application>Same GNOME</application> game is used as an example.

53.

<application>Same GNOME</application> is the program we will be using as an example. Be warned that, since valgrind emulates the CPU, it will run <emphasis>very</emphasis> slowly. You will also need a lot of memory.

57.

<application>Massif</application> output for the unoptimized version of the <application>Same GNOME</application> program.

58.

<xref linkend="optimization-massif-FIG-output-unoptimized"/> shows a typical postscript output from <application>Massif</application>. This is the result you would get from playing a single game of <application>Same GNOME</application> (version 2.8.0) and then quitting. The postscript file will have a name like <filename>massif.12345.ps</filename> and the text file will be called <filename>massif.12345.txt</filename>. The number in the middle is the process ID of the program that was examined. If you actually try this example you will find two versions of each file, with slightly different numbers, this is because <application>Same GNOME</application> starts a second process and <application>Massif</application> follows that too. We will ignore this second process, it consumes very little memory.

60.

Command: ./same-gnome

== 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)

62.

== 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 (same-gnome.c:463)

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

and 1 other insignificant place

63.

The first line tells us we are now four levels deep into the stack. Below it is a listing of the function calls that leads from here to gdk_pixbuf_new. Finally there is a list of functions that are at the next level down and call these functions. There are, of course, also entries for levels 1, 2, and 3, but this is the first level to reach right down through the GDK code to the <application>Same GNOME</application> code. From this listing, we can see instantly that the problem code is load_scenario.

67.

Unfortunately, the choice of optimization is also constrained by the needs of the program. The size of the pixbuf data in <application>Same GNOME</application> is determined by the size of the game's graphics and cannot be easily reduced. However, the amount of time it spends loaded into memory can be drastically reduced. <xref linkend="optimization-massif-FIG-output-optimized"/> shows the <application>Massif</application> analysis of <application>Same GNOME</application> after being altered to dispose of the pixbufs once the images have been loaded into the X server.

68.

<application>Massif</application> output for the optimized <application>Same GNOME</application> program.

71.

Command: ./same-gnome

== 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)