GSlice with tight memory (Re: Help Needed)

[Tim Janik <timj imendio com>]

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
> > constraints.
> >
> >   Federico

> 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
savings.
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.

---
ciaoTJ