mirror of
https://gitlab.gnome.org/GNOME/glib.git
synced 2025-08-30 12:54:11 +02:00
1312ec6d0b
It seems bad style, to use a naive realloc() +1 increment each time a new element gets added. Instead, remember the allocation size and double the buffer size on buffer grow. This way we get linear amortized runtime complexity for buffer growth. Well, WeakRefStack uses a flat array for tracking the entires. We anyway need to search and memmove() the entries and are thus O(n) anyway. We do that, because it allows for relatively simple code while being memory efficient. Also, we do expect only a reasonably small number of weak notifications in the first place. I still think it makes sense to avoid the O(n) number of realloc() calls on top of that. Note that we do this while holding the (per-object) lock. It's one thing to do a linear search or a memmove(). It's another to do a (more expensive) realloc(). Also, shrink the buffer during g_object_weak_unref() to get rid of excess memory. Also, note that the initial allocation only allocates space for the first item. I think that makes sense, because I expect that many objects will only get a single weak notification registered. So this allocation should not yet have excess memory allocated. Also, note that the "flexible" array member WeakRefStack.weak_refs has a length of 1. Maybe we should use C99 flexible array members ([]) or the pre-C99 workaround ([0]). Anyway. Previously, we would always allocate space for that extra one tuple, but never use it. Fix that too.