a glist (list of graphical objects) is internally implemented as a linked list. usually, a big
advantage of a linked lists is that adding/deleting elements won't touch other elements
(especially doesn't move them in memory, like it can happen with dynamically sized arrays).
That's the theory.
In practice the insidious audio dropouts happen when Pd is
*iterating* over a glist, not when adding/deleting objects.
This is because users learn relatively quickly the simple rule
that adding/deleting objects rebuilds the signal graph, so they
avoid doing that if at all possible during performance.
However, users generally have no idea what triggers a walk through
the glist linked list. And those trips can easily cause dropouts
during a performance-- even merely moving the mouse over a canvas.
So in practice, glist as linked list optimizes for the case not
often used in realtime performance and is a detriment to performance
in the cases where it matters (esp. compared to iterating over an
array, though the number of glist iterations with things like
mouse motion might trip up audio anyway).
-Jonathan