Re: memory allocations.

[Havoc Pennington <hp redhat com>]

Hi,

So hacking memprof to never free any of the blocks it's tracking, and
adding some columns to the profile, I counted the total of all calls
to malloc instead of just those that are not freed. The count is not
really a lot larger than the count of those freed, most allocated
memory on startup is kept around rather than released.

If I profile gtk-demo coming onscreen and then being closed (a tree
widget, couple text widgets, and menus/labels), total allocations is
about 17000.

The top of the profile is 5358 blocks allocated for g_strndup with
block size ranging from 3 to 61, and 1113 blocks allocated for text in
the text widget, with block size ranging from 18 to 113. So the top of
the profile is strings by a large margin.

After that memprof claims gtk_bin_get_child allocates 1012 blocks with
a range of sizes from 10 to 36, but this is just bullshit and probably
some sort of bug in memprof's stack tracing. So who knows what these
blocks really are.

Then realloc which is 807 blocks from 4 to 2560 in size. The caller of
realloc is almost always one of the "expand a dynamic array" or
"append to a string" functions.

Then we have g_type_create_instance() which allocates 675 blocks
ranging from 16 to 752 bytes for GObject subclasses. Some of these are
in mem pools.

Then pango_x_insert_font() which is the largest current memory user
due to the fontmap size; allocates 595 blocks from 8 to 81 bytes. This
is mostly font name strings I believe. It varies wildly depending on
how many fonts you have installed.

Hash/list node and other mempools are only responsible for about 100
allocs, to create or expand the pools.

If I build GLib with --disable-mem-pools to turn off mempools, the
total allocs goes from 17000 to 26000, with g_slist_alloc topping the
profile with 6310 blocks. 

Conclusion, we are already using mem pools to cut allocations from
26000 to 17000, and our current allocations are almost all strings and
variable-length arrays.

Havoc