On 15/10/2011 00:08, Lex Trotman wrote:
- gslice is good when you allocate lots of things the same size, and
you know the size, since that must be supplied to slice_free, but a large portion of our allocations are strings, so we don't remember the size (see for eg tagmanager).
Yes, by fixed size alloc I meant fixed size types, not strings.
Secondly, see: http://developer.gnome.org/glib/2.28/glib-Memory-Slices.html#glib-Memory-Sli...
"This is accompanied by extra caching logic to keep freed memory around for some time before returning it to the system."
Yes, it waits 15 seconds before freeing empty slabs back to the system, thats what I mean by "each of which has differing policies for holding onto memory". This is actually observable, but it only frees about 100k of the 28Mb. malloc and C++ work differently.
Thirdly, GLib recommends using g_slice for fixed size allocations, and IIUC g_slice completely prevents fragmentation, besides being faster (anecdotally about 2x).
No, even the glib developers don't claim it completely prevents fragmentation :) It completely prevents *internal* fragmentation
Agreed.
within a slab since all chunks are the same size, but no slab can be returned to the system or re-used for another size if it has any chunks still in use. And this form of fragmentation is very likely since Geany and GTK and tagmanager etc all hold on to random bits of memory (because they need to, its not a bug), thus blocking release of slabs.
Yep, this is a problem.
I don't know if converting our other uses of g_new for fixed size structures is worth it, but I would say it is good practice to use g_slice in all new code.
Agree, I don't think we are going to be able to totally cure the "problem" but we can waste lots of effort on it.
Actually it probably depends on the context as to whether g_slice is a good idea.