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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html