This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] Calling realloc vs. mallo/memcpy/free and _IO_vasprintf.
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Siddhesh Poyarekar <sid at reserved-bit dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 27 Nov 2015 01:09:22 -0500
- Subject: Re: [RFC] Calling realloc vs. mallo/memcpy/free and _IO_vasprintf.
- Authentication-results: sourceware.org; auth=none
- References: <5657C135 dot 1090807 at redhat dot com> <20151127031433 dot GA5012 at devel dot intra dot reserved-bit dot com> <5657EC65 dot 6090001 at redhat dot com> <20151127054345 dot GA7124 at devel dot intra dot reserved-bit dot com>
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.