On Wed, 2013-06-26 at 12:34 +0200, David Henningsson wrote: > On 06/26/2013 12:22 PM, Tanu Kaskinen wrote: > > On Wed, 2013-06-26 at 11:48 +0200, David Henningsson wrote: > >> On 06/19/2013 05:40 PM, Tanu Kaskinen wrote: > >>> A dynamic array is a nice simple container, but the old interface > >>> wasn't quite what I wanted it to be. I like GLib's way of providing > >>> the free callback at the container creation time, because that way > >>> the free callback doesn't have to be given every time something is > >>> removed from the array. > >>> > >>> The allocation pattern was changed too: instead of increasing the > >>> array size always by 25 when the array gets full, the size gets > >>> doubled now. > >> > >> Not sure if you need this now that the node ownership stuff is changed, > > > > I guess I don't need this now, but I'd still like to have this change in > > dynarray. Is it OK for you? > > Yes, I'm okay with the rest of the changes. I noticed that dynarray_get > semantics changed for getting element outside the array - I'm okay with > the change but please go through the callers thoroughly to make sure we > don't get assertion failures when we shouldn't. > > >> but anyway, it makes sense to have both (new_size = old_size * 2 + 25), > >> both as an optimisation in the beginning, and especially so if > >> n_allocated ever gets down to zero (I don't know if that can happen). > > > > n_allocated never decreases (at the moment anyway - I could implement > > that if there is demand). > > > > I see the point of optimizing in the beginning. Currently the array > > starts with allocated size of 1, so reallocations will happen when the > > size reaches 2, 3, 5, 9, 17, 33... Starting with size 25 would perhaps > > be better. > > > > So if we start with n_allocated = 25 and increase with max(n_allocated * > 2, 25), does that work for you? Sure. It's only a safety mechanism against future bugs (for the case when n_allocated goes to 0), but I'm OK with that. -- Tanu
