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: Siddhesh Poyarekar <sid at reserved-bit dot com>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 27 Nov 2015 08:44:34 +0530
- 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>
On Thu, Nov 26, 2015 at 09:34:29PM -0500, Carlos O'Donell wrote:
> While answering a question on libc-help about asprintf I happened
> to look at _IO_vasprintf and noticed some code which tries to
> decide if it should do a realloc vs. malloc/memcpy/free.
>
> In this particular case we should always be shrinking the buffer.
> For example _IO_vfprintf may have expanded the stream buffer but
> now no longer needs the extra space. If we are growing the buffer
> then something is very very wrong since that means _IO_vpfrintf
> will have failed due to lack of memory, and we handled that case
> earlier in _IO_vasprintf.
>
> So again, if we are only shrinking the buffer, then realloc has
> to be the most optimal operation in all cases. It would seem to
> me that an allocation shrink like this would almost never result
> in an allocation move, but rather malloc would just split the
> allocation and reuse the remainder for other malloc calls.
>
> So why the micro-optimization?
>
> Is my assumption of always shrinking the buffer wrong?
>
> If my assumption is right, and my logic is right, wouldn't the
> following patch be a natural cleanup?
Why would malloc+memcpy+free be faster than a realloc, which does the
same thing internally, but without adding the extra PLT and avoiding
memcpy for smaller copies? I'd say just drop that bit and stick to
realloc.
Siddhesh