This article describes how to use the
The heap is the region of memory which is allocated with functions like malloc. It grows on demand and is usually the largest region of memory in a program. The stack is where all the local data for functions is stored. This includes the "automatic" variables in C and the return address for subroutines. The stack is typically a lot smaller and a lot more active than the heap. We won't consider the stack explicitly since
It is also useful to tell
A súa liña de orde debería semellarse a esta:
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
The graphical output of
O ficheiro de texto está ordenado como unha xerarquía por seccións, na parte superior está unha lista dos peores usuarios da memoria para reducir o espazotempo. Máis abaixo de isto están as seguintes sección, cada unha delas dividindo os resultados en maior detalle como se procedera cara abaixo na pila de chamadas. Para ilustrar isto usaremos a saída da orde de arriba.
The image above shows a typical postscript output from
Na parte superior da gráfica vese unha gran banda amarela etiquetada como gdk_pixbuf_new. Semella un candidato ideal para a optimización, pero precisarase usar o ficheiro de texto para topar que está chamando a gdk_pixbuf_new. A parte superior do ficheiro de texto mostrará algo como o seguinte:
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)
The line with the '=' signs indicates how far down the stack trace we are, in this case we are at the top. After this it lists the heaviest users of memory in order of decreasing spacetime. Spacetime is the product of the amount of memory used and how long it was used for. It corresponds to the area of the bands in the graph. This part of the file tells us what we already know: most of the spacetime is dedicated to gdk_pixbuf_new. To find out what called gdk_pixbuf_new we need to search further down the text file:
== 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
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
Agora que sabe que parte do código usa todo o espazo de tempo pódese buscar o porque. Resulta que load_scenario está cargando un pixbuf dun ficheiro e nunca libera esa memoria. Tendo identificado o código do problema pódese comezar a arranxalo.
Reducir o consumo do espazo de tempo é bo, pero hai dúas formas de reducilo e non son iguais. Pode tanto reducir a cantidade de memoria reservada como reducir a cantidade de tempo na que está reservada. Considere por un momento un sistema modelo con só dous procesos executándose. Ámbolos dous procesos usan case toda a RAM física e superpóñense por completo polo que o sistema terá que usar a swap e todo se ralentizará. Se no lugar disto reducimos o tempo que está reservada a memoria por un factor de dous entón os dous programas poden coexistir, pero mentres os seus períodos de alto uso de memoria non se superpoñan. Polo tanto é mellor reducir o consumo de memoria reservada.
Unfortunately, the choice of optimization is also
constrained by the needs of the program. The size of the
pixbuf data in
O uso do espazo de tempo do gdk_pixbuf_new é agora unha banda máis estreita que só ten picos moi brebes (agora é a dezaseisava banda e pintada en maxenta). Ademáis, o pico de uso de memoria baixou 200 kB xa que o pico se produce antes de que se reserve outra memoria. Se dous procesos como este estiveran executándose á vez as opcións dun pico de uso de memoria coincidente, e polo tanto o risco de facer swapping, serán moi poucas.
Can we do better ? A quick examination of
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)
Se miramos máis cerca nas partes que vemos se chaman desde moitas partes.
== 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
Agora encárase a redución da saída para os esforzos de optimización. O gráfico suxire outra posíbel aproximación: tanto a banda «other» como a «heap admin» son bastante largas. Isto quere dicir que existen moitas pequenas reservas realizadas desde certa variedade de sitios. Eliminalos será difícil, pero se se poden agrupar, entón as reservas son individuais poden ser máis grandes e a elevada banda «heap admin» pode reducirse.
Existen un par de cousas para ter en conta: Primeiramente, só se informa do espazo de tempo como porcentaxe, ten que comparalo co tamaño total do programa para decidir se merece a pena perseguir a cantidade total de memoria. O gráfico, co seu eixe vertical de kilobytes, é bo para iso.
Secondly,