glib/gobject
Thomas Haller a2da296230 gobject: optimize notify-queue handling for a single freeze
When we set a property we usually tend to freeze the queue notification
and thaw it at the end. This always requires a per-object allocation
that is necessary to track the freeze count and frozen properties.

But there are cases cases, where we freeze only a single time and never
add a property to unfreeze. In such cases, we can avoid allocating a new
GObjectNotifyQueue instance.

Optimize for that case by initially adding a global, immutable sentinel
pointer "notify_queue_empty". Only when requiring a per-object queue,
allocate one.

This can be useful before calling dispose(). While there are probably
dispose functions that still try to set properties on the object (which
is the main reason to freeze the notification), most probably don't. In
this case, we can avoid allocating the memory during g_object_unref().

Another such case is object construction. If the object has no construct
properties and the user didn't specify any properties during
g_object_new(), we may well freeze the object but never add properties
to it. In that case too, we can get away without ever allocating the
GObjectNotifyQueue.
2025-04-03 18:13:39 +02:00
..
2023-10-16 23:34:04 +01:00
2023-12-31 09:09:48 +00:00
2022-10-13 20:53:56 -04:00
2023-10-16 23:35:05 +01:00
2023-12-31 09:09:48 +00:00
2022-10-13 20:53:56 -04:00
2023-10-16 23:34:24 +01:00
2022-10-13 20:53:56 -04:00
2022-10-13 20:53:56 -04:00
2025-02-10 10:26:42 +01:00
2023-10-23 11:26:53 +01:00
2022-10-13 20:53:56 -04:00