GNOME Bugzilla – Bug 624977
GDBusMessage: _new() functions do more than call g_object_new().
Last modified: 2011-02-15 09:50:47 UTC
Functions like g_dbus_message_new_method_call() should generally just be C convenience functions, leaving language bindings to call g_object_new() with the appropriate property values. But the g_dbus_message_new*() functions do more than that. This is a difficulty for glibmm.
(In reply to comment #0) > Functions like g_dbus_message_new_method_call() should generally just be C > convenience functions, leaving language bindings to call g_object_new() with > the appropriate property values. But the g_dbus_message_new*() functions do > more than that. This is a difficulty for glibmm. Actually, if you check the history, GDBusMessage used to use GObject construct properties and all the good stuff that slowed down things - but I decided this was too much overhead so I cut the properties and just moved things into the _new*() functions (we also did this for a number of other types). Note that this is not unique to GDBusMessage - a number of other GObject-derived types in GIO does the same. For example, what does glibmm do g_simple_async_result_new_from_error()?
Hmm, maybe it was only GDBusMethodInvocation we removed the properties from, see http://git.gnome.org/browse/glib/commit/?id=ab2ff1a307f6bf7825e02b0d09e25b8ea7570c07 the thinking was something along the line that users would never need to create such instances themselves. The same logic doesn't quite hold for GDBusMessage though. Anyway, I'm curious to know what you do for e.g. GSimpleAsyncResult in glibmm.
(In reply to comment #2) > Anyway, I'm curious to know what you do for e.g. GSimpleAsyncResult in > glibmm. We don't wrap it, probably because it doesn't seem to be used in any of the glib API. I guess it's used in glib (or gio) implementation only. Why did you think the overhead was more of an issue for GDBusMessage than for other types?
(In reply to comment #3) > Why did you think the overhead was more of an issue for GDBusMessage than for > other types? Mostly because GDBusMessage is not supposed to be subclassed, it doesn't emit signals (it probably should have been a boxed type rather than a GObject-derived one) and instances of the type may be constructed/finalized very often. Btw, when I use the word overhead, I refer to both the run-time cost of shoveling things through GValue / GValueArray (with the copies that involve etc.) but also how properties require more lines of code and adds unneeded complexity (and also evicting useful code from the CPU instruction caches) etc. etc. I'm actually more concerned about the latter but the former might show up on slow machines and/or in messaging-intensive apps. I haven't benchmarked anything though. Don't you have a way in glibmm to handle this manually?
Yes, we can handle this, and it's only a real issue for GTypes that have signals or vfuncs, which is not the case for this one. So, we'd prefer it to be done properly either as a boxed type or a purer GObject, but we can live with it.