This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Calling realloc vs. mallo/memcpy/free and _IO_vasprintf.


On 11/27/2015 12:43 AM, Siddhesh Poyarekar wrote:
> On Fri, Nov 27, 2015 at 12:38:45AM -0500, Carlos O'Donell wrote:
>> I still don't see how realloc is going to be slower since it's just
>> one call, and there *might* be enough space in this chunk or the next
>> to grow by one byte and that avoids the memcpy.
> 
> Agreed, in fact even in the mremap case you mentioned, the
> malloc+memcpy+free ought to be slower because you end up calling two
> syscalls (mmap followed by munmap) instead of just mremap in case of
> realloc.  I don't think there is a situation where realloc calls
> mremap and the malloc+memcpy+free combination allocates on the heap.

The *only* interesting case is: What if we don't realloc a too-large buffer?

What if we kept the too-large buffer, null-terminated the string, and
returned that to the caller? You are trading off size of allocated
buffer versus realloc cost.

My reading of vfprintf.c shows that we malloc rather conservatively
to grow the working buffer as we memcpy (xsputn) the results into place.
Therefore the working buffer shouldn't be that much larger than what's
needed, and that means we might just get away with avoiding the realloc
in the case the buffer is more than 1 byte (for NULL) larger than required?

So in 2000 (15 years ago), Ulrich added this code, it previously did
an unconditional realloc as we suggest today.

The comment was:

commit 4100c5a0e62c461adf2757a163dafbbc02ca3fc4
Author: Ulrich Drepper <drepper@redhat.com>
Date:   Tue Apr 11 17:53:41 2000 +0000

    (_IO_vasprintf): Try to avoid memory fragmentation by allocating
    new memory at the end instead of reallocating.

I agree that realloc has the potential to fragment the arena, but we have
no tools to measure this. If we are going to micro-optimize to reduce
heap fragmentation we are going to need a lot more instrumentation in
malloc.

Thoughts?

Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]