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.
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.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. Soren
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??