GNOME Bugzilla – Bug 618559
inefficient variant handling in gdbusproxy
Last modified: 2010-05-13 21:00:38 UTC
Created attachment 160987 [details] [review] patch I noticed that gdbusproxy.c:on_properties_changed handles the GVariant's somewhat inefficiently; attached patch fixes that. The only behavioural change is that the changed_properties and invalidated_properties parameters send to the gobject signal are now present even when they're really empty; if that was by design, it's of course easy to add that back: - changed_properties, - _properties); + _variant_n_children (changed_properties) != 0 ? changed_properties : NULL, + _properties[0] != NULL ? invalidated_properties : NULL); Also, if in this part of the code: g_variant_get (parameters, "(&s@a{sv}^a&s)", &interface_name_for_signal, &changed_properties, &invalidated_properties); if (g_strcmp0 (interface_name_for_signal, proxy->priv->interface_name) != 0) goto out; the condition turns out to be often true, so that unpacking the changed_properties and invalidated_properties would be in vain, the code could even be amended to only unpack the interface_name_for_signal first, check, and only then unpack the others.
(In reply to comment #0) > Created an attachment (id=160987) [details] [review] > patch Looks good. Applied. > The only behavioural change is that the changed_properties and > invalidated_properties parameters send to the gobject signal are now > present even when they're really empty; if that was by design, it's > of course easy to add that back: I think it might be nicer to actually guarantee that they're never NULL. I've changed the docs (and example) to reflect that http://git.gnome.org/browse/glib/commit/?h=gdbus-merge&id=3ca28ef718d402bd65cd9f291c67b299f1ef74cf Thanks, David