After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 418970 - Avoid trivial allocations during g_object_notify()
Avoid trivial allocations during g_object_notify()
Status: RESOLVED OBSOLETE
Product: glib
Classification: Platform
Component: gobject
2.12.x
Other Linux
: Normal minor
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2007-03-16 14:01 UTC by Chris Wilson
Modified: 2014-12-22 17:58 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Avoid trivial allocs in g_object_notify() (3.35 KB, patch)
2007-03-16 14:03 UTC, Chris Wilson
rejected Details | Review

Description Chris Wilson 2007-03-16 14:01:40 UTC
1. GObjectNotifyQueue abuses the GList allocator, however GSlice obsoletes that and supplies a generic allocator perfect for use here...
2. Frequently g_object_notify() is run immediately (e.g. the GtkAdjustment emitting value-changed...) and so only has a single member in its list. We can avoid the allocation overhead here and embed one GSLink into the NotifyQueue struct.


Does GObjectNotifyQueue count as a public ABI since the .c file (and its "private" definitions) is #included into other projects?
Comment 1 Chris Wilson 2007-03-16 14:03:00 UTC
Created attachment 84714 [details] [review]
Avoid trivial allocs in g_object_notify()
Comment 2 Chris Wilson 2007-03-16 14:08:30 UTC
Hmm, missed one controversial aspect of that patch - it delays the free of the GObjectNotifyQueue til object destruction rather than recreating a new GObjectNotifyQueue for each g_object_notify()
Comment 3 Stefan Sauer (gstreamer, gtkdoc dev) 2008-10-20 11:21:46 UTC
Looks good. Wonder what the glib maintainers think about it.
Comment 4 Tim Janik 2008-10-20 11:49:55 UTC
I fail to see an obvious improvement in this patch. Granted, the current code should be mildly cleaned up to use GSlice instead of the list allocator functions at this point. However, trying to "save" the initial list node allocation in the pspec queue is quite pointless in my eyes, because GSlice already gives us a fast portable allocation mechanism (for the most part, allocating a list node amounts to popping a node from a per-thread free list) and it obfuscates the list handling (apart from failing to free the notification queue as comment #2 points out). It'd be interesting so see any benchmarks that back the idea that this could have a *significant* performance impact.
Comment 5 Sven Neumann 2008-10-21 07:21:58 UTC
Perhaps a patch that only changes the code to use GSlice would be a good start? Based on that, additional improvements can be benchmarked and discussed then.
Comment 6 Emmanuele Bassi (:ebassi) 2014-12-22 17:58:23 UTC
the code in gobjectnotifyqueue.c was merged inside gobject.c in commit:

commit 128862eafe49b5454c4b32b0866800d4aa7c53f3
Author: Ryan Lortie <desrt@desrt.ca>
Date:   Wed Nov 16 15:31:58 2011 +0000

    [notify] merge gobjectnotifyqueue.c into gobject.c

and the code cleaned up. gobjectnotifyqueue.c is still available because it's included directly by other projects, but it won't see any further changes.