Re: GSlice with tight memory (Re: Help Needed)

Soeren Sandmann wrote:
Tim Janik <timj imendio com> writes:

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.

In general, I'd recommend just always using

        g_slice_set_config (G_SLICE_CONFIG_ALWAYS_MALLOC, 1);

This way the various tools, valgrind and memprof, will work with your
application, and you don't get any surprises with pathological cases
causing run-away caching. The speed difference between g_slice and
g_malloc is basically noise as soon as you include the time to
initialize the new block of memory.

If it does turn out that malloc() shows up on a profile (either memory
or speed), those specific cases can be fixed. With application
knowledge you can do a better job than any general purpose allocator.

I have already tested g_slice_set_config for always malloc and also for disabling magazine layer. This helps me in my application. But the major problem is application development is not in my hand. This will be done by the third party which will be using the normal glib wrappers without knowing the underline memory management. I m porting the glib on an embedded arm architecture where my cache is also very small. So the allocation done by slab allocator wont be much effective cause the size of the chunk will be fixed may be its 100k app or 1Mb app.

Can i implement something like dynamic slab allocator? in which i can vary the chunk/slab size depending upon the application requirment using some mechanism like memory pressure??

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