GSlice with tight memory (Re: Help Needed)

On Fri, 18 Aug 2006, Kaustubh Atrawalkar wrote:

Federico Mena Quintero wrote:

You can certainly make that number smaller.  Remember that on average
half of G_QUARK_BLOCK_SIZE will be "wasted space" from the unused
entries at the end of the array.  On a 32-bit machine, this would be
512 * sizeof (gpointer) / 2 = just 1 KB per process.  That's probably
too small a value to optimize for, unless you have *really* tight


Yes we have *really* tight constraints. One more thing about the slab
allocator. As per my study the slab allocator uses POSIX_MEMALIGN to
allocate blocks of memory at a time though only small amount of that is
used at that time.

the slab allocator, like most other allocators, allocates blocks which are
a multiple of the requested chunk size. that's done based on the observation
that most chunk sizes are allocated more often than once.
so beyond the first time a chunk size is allocated, the "big" initial
allocation starts to pay off and can eventually even result in significant
apart from that, any other allocator you use (glibc malloc/free) will
behave the same way and implement "cacheing" behaviour in one way or another.

This chunk size can be set and can be disabled
through G_SLICE environment variable. My requirement of memory is at the
most 2Mb (means the apps wont exceed this limit) then can removing the
slab allocator will help me ? I can see the noticeable change in small
apps (less than aroung 300/400k) but not in large apps. Comment plz.

whether you benefit in terms of memory size by using GSlice instead of
malloc/free depends heavily on your application. simply watch your
memory requirements with G_SLICE=always-malloc and without it.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]