This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Enhancing malloc
- From: Nix <nix at esperi dot org dot uk>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: Siddhesh Poyarekar <siddhesh at redhat dot com>, Will Newton <will dot newton at linaro dot org>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Tue, 28 May 2013 21:00:09 +0100
- 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> <20130528130200 dot GA17671 at domone dot kolej dot mff dot cuni dot cz>
On 28 May 2013, OndÅej BÃlka stated:
> On Tue, May 28, 2013 at 06:24:44PM +0530, Siddhesh Poyarekar wrote:
>> On Tue, May 28, 2013 at 02:33:17PM +0200, OndÅej BÃlka wrote:
>> > 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.
>>
> This depends if you use bash time builtin or /usr/bin/time.
> Later has all information needed (but better formating than default is
> welcome, see below.)
Not so. /usr/bin/time certainly does not report arena fragmentation in
any fashion. Memory usage != arena fragmentation.
--
NULL && (void)