From: Jeff King <peff@peff.net>
Date: Thu, 08 Nov 2012 16:38:03 GMT
Subject: Re: [PATCH 1/4] strbuf_split_buf(): use ALLOC_GROW()
Message-ID: <20121108163803.GE15560@sigill.intra.peff.net>
In-Reply-To: <5098C21F.6030803@alum.mit.edu>

On Tue, Nov 06, 2012 at 08:54:07AM +0100, Michael Haggerty wrote:

> > I suspect this was not used originally because ALLOC_GROW relies on
> > alloc_nr, which does fast growth early on. At (x+16)*3/2, we end up with
> > 24 slots for the first allocation. We are typically splitting 1 or 2
> > values.
> > 
> > It probably doesn't make a big difference in practice, though, as we're
> > talking about wasting less than 200 bytes on a 64-bit platform, and we
> > do not tend to keep large numbers of split lists around.
> 
> I did a little bit of archeology, and found out that
> 
> * ALLOC_GROW() did indeed exist when this code was developed, so it
>   *could have* been used.
> 
> * OTOH, I didn't find any indication on the mailing list that the
>   choice not to use ALLOC_GROW() was a conscious decision.
> 
> So history doesn't give us much guidance.

Thanks for digging.

> If the size of the initial allocation is a concern, then I would suggest
> adding a macro like ALLOC_SET_SIZE(ary,nr,alloc) that could be called to
> initialize the size to some number less than 24.  Such a macro might be
> useful elsewhere, too.  It wouldn't, of course, slow the growth rate
> *after* the first allocation.

I think we are getting into premature optimization territory. Let's
take your series as a cleanup, and we can worry about micro-optimizing
the allocation if and when it ever becomes an issue.

-Peff