[pulseaudio-discuss] [PATCH 15/21] dynarray: Reimplement with nicer semantics
david.henningsson at canonical.com
Wed Jun 26 03:34:53 PDT 2013
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?
David Henningsson, Canonical Ltd.
More information about the pulseaudio-discuss