This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 06/25] Add struct scratch_buffer and its internal helper functions
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: Paul Eggert <eggert at cs dot ucla dot edu>, libc-alpha at sourceware dot org
- Date: Fri, 3 Apr 2015 18:25:31 +0200
- Subject: Re: [PATCH 06/25] Add struct scratch_buffer and its internal helper functions
- Authentication-results: sourceware.org; auth=none
- References: <cover dot 1425285061 dot git dot fweimer at redhat dot com> <7a6fe503fb764beee3d5b89662d3bbf65242161c dot 1425285061 dot git dot fweimer at redhat dot com> <54F4BB15 dot 7070409 at cs dot ucla dot edu> <550C37F7 dot 10504 at redhat dot com>
On Fri, Mar 20, 2015 at 04:08:39PM +0100, Florian Weimer wrote:
>
> >> + size_t new_length = buffer->length * 2;
> >
> > In Gnulib we originally did it this way, but nowadays we grow by a
> > factor of 1.5 (new_length = old_length + old_length / 2 + 1) rather than
> > by a factor of 2, as this was less jerky for large buffers. Perhaps do
> > something similar here?
>
> I think we should leave the fine-tuning to a later stage. See also the
> comment above about malloc_usable_size.
>
> The original code used a growth factor of 3 during the alloca phase, and
> 2 during the malloc phase. (After the i386 ABI change for stack
> alignment, it's effectively 2 and 2.)
>
That does not make much sense. Its mostly used in funcions that cannot
realloc array themself so we double space until it fits. As its
temporary its better to overallocate than try save space.
You could use factor 16 to improve performance. If large buffers are
concern then add treshold after which you use 1.5 but I doubt that you
reach 1MB with functions used.