This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Enhancing malloc
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: OndÅej BÃlka <neleai at seznam dot cz>, Will Newton <will dot newton at linaro dot org>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Tue, 28 May 2013 15:46:25 -0400
- Subject: Re: Enhancing malloc
- References: <CANu=Dmj34hZoWr8A5dPThv14XUmP8vTgsxFLAbJ9jTTabRPqqA at mail dot gmail dot com> <20130528123317 dot GA17360 at domone dot kolej dot mff dot cuni dot cz> <20130528125444 dot GC2145 at spoyarek dot pnq dot redhat dot com>
On 05/28/2013 08:54 AM, Siddhesh Poyarekar wrote:
> On Tue, May 28, 2013 at 02:33:17PM +0200, OndÅej BÃlka wrote:
>> Malloc and friends are one of few libc functions which can be measured
>> directly. They account to about 50% of time spend in libc. I know that gcc
>> hevavily uses malloc. So authoritative test could be if following is
>> improvement or not:
>>
>> for I in `seq 1 10` do
>> echo new
>> LD_PRELOAD=new_malloc.so time gcc test.c
>> echo old
>> time gcc test.c
>> done
>>
>> You must take into account that malloc requests are small. I did some
>> measurements at
>> http://kam.mff.cuni.cz/~ondra/benchmark_string/malloc_profile_28_11_2012.tar.bz2
>
> For malloc and friends, the comparison should also include the effect
> of the change on fragmentation (internal as well as external) and not
> just speed of execution.
I agree.
In glibc's allocator we consciously try to collesce fastbins and use
MADV_DONTNEED to give back unused pages.
We could get a performance boost by looking at the new vrange support.
Such support has already been tested in jemalloc and shown to potentially
improve performance.
Cheers,
Carlos.