gslice allocator: general impresions.

[Michalis Giannakidis <mgiannakidis gmail com>]

Dear Glib team,

I have recently used the glib-glice allocator in a very malloc intensive 
application, and I would like to share a few observations I made, with you.

The typical size I send to g_slice_alloc is 20 and 76 bytes (32 bit build). 
The total memory consumed by my application has decreased - which is great! 
However it `seems' to me,  that this decrease in size is larger for the 64bit 
build compared to the 32bit build. (I have modified gslice to align a chunk 
to its own size so that I don't have unused memory between chunks eg: request 
20 and get 24...)

In my application now I use both g_slice_alloc and malloc.Testing the new 
allocator in linux I came accross the following: 
After using g_slice_alloc to alloc a great amount of data (eg 1500mb), each of 
them being 20 or 76 bytes in size, subsequent calls to malloc(8*1024) or 
similar sizes take much longer (the allocation does _not_ got to the swap). 
Also if I chage the min_page_size from 128 to 4096, then the subsequent calls 
to malloc(8*1024) or similar sizes take even longer. It takes for ever in the 
64 bit build! 
Moreover, even with min_page_size set to 128, the calls to malloc take for 
ever on a Linux 2.4.20 glibc-2.2.4(glibc up to 2.2.5 has a broken 
posix_memalign so I  fallback to memalign).
In all of the cases above, malloc responds much faster when the gslice 
allocator is turned off.

I know I should be providing sample code  and test programms here to back up 
my observations. I also understand that I should provide execution times 
instead of just stating that the calls to malloc take for ever.

I would like to ask you, if there are any known issues in mixing gslice and 
malloc calls in malloc intensive applications.
Any suggested readings would be most  welcome.

Regards
Michalis
-- 
Michalis Giannakidis