GNOME Bugzilla – Bug 634471
GDBus Optimizations
Last modified: 2018-05-24 12:52:01 UTC
I was considering using gdbus for new code I write in AT-SPI, so I wrote a couple of simple tests to compare its performance to that of libdbus. I created a program that would call GetConnectionUnixProcessID 20000 times using libdbus and an equivalent program using gdbus. I timed the programs on my Thinkpad T61 laptop (2.4ghz Pentium Core 2 Duo 7700 cpu) and got the following results: Real: 9.132 s for gdbus; 2.321 s for libdbus User: 6.536 s for gdbus; 0.744 s for libdbus System: 0.8 s for gdbus; 0.208 s for libdbus Gprof gives me the following, although I don't know how useful it wil be: % cumulative self self total time seconds seconds calls ms/call ms/call name 16.23 1.19 1.19 g_variant_type_string_scan 9.75 1.91 0.72 g_atomic_pointer_get 4.43 2.23 0.33 g_atomic_int_get 3.41 2.48 0.25 pthread_mutex_lock 2.59 2.67 0.19 g_variant_type_get_string_length 2.59 2.86 0.19 g_type_check_instance_is_a 2.46 3.04 0.18 g_variant_type_check 2.32 3.21 0.17 __pthread_mutex_unlock_usercnt 2.32 3.38 0.17 g_type_check_instance_cast 1.84 3.52 0.14 g_atomic_int_compare_and_exchange 1.77 3.65 0.13 g_variant_type_info_assert_no_infos 1.64 3.77 0.12 _int_malloc 1.50 3.88 0.11 g_variant_type_equal 1.50 3.99 0.11 memcpy 1.23 4.08 0.09 malloc 1.09 4.16 0.08 cfree 1.09 4.24 0.08 g_variant_type_peek_string 1.02 4.31 0.08 g_atomic_int_exchange_and_add
Created attachment 174173 [details] Equivalent test app using libdbus.
Definitely not opposed to optimizing GDBus or GVariant at all (and there is surely a lot of low-hanging fruit - especially for arrays of scalar types). In fact, I'm actually surprised we are only slower by a factor of 4 :-) Anyway, please realize that such benchmarks are kind of worthless. To elaborate: if you are using D-Bus in a way that requires hammering data back and forth, then you are doing it wrong. Instead, you should consider - using a UNIX socket e.g. instead for the main data pipe (much like e.g. GVfs is doing for streaming I/O) - fix your protocol / D-Bus API so it's better at caching (using e.g. D-Bus properties, specifically GetAll() and the new ::PropertiesChanged signal) - not using blocking, synchronous calls from a single thread - use worker threads if synchronous, blocking calls are needed Disclaimer: I don't know enough about AT-SPI to say what kind of the above problems it suffers from (if any). That said, patches are of course welcome etc. Please just realize that the goal of GDBus is not to be a more performant D-Bus implementation than libdbus-1... the goal is is to have an implementation that a) works with modern GIO abstractions (such as running the connection over any GIOStream) b) works with threads (e.g. have many worker threads each doing blocking calls) c) works with GVariant d) is pleasant to use for the programmer - e.g. no abort() - g_return_if_fail() - UTF-8 checks
(In reply to comment #1) > Created an attachment (id=174173) [details] > Equivalent test app using libdbus. Btw, did you mean to attach source code for the GDBus app? I don't see it anywhere...
Comment on attachment 174173 [details] Equivalent test app using libdbus. (While text/x-csrc is technically more accurate, text/plain will make it show in a browser tab on most systems. So changing it to the latter.)
Created attachment 174245 [details] Test using gdbus. Oops--I neglected to add this when I filed the bug.
Thanks - I just ran the gdbus one under sysprof, here's the result http://people.freedesktop.org/~david/gdbus-sysprof-snapshot.png Not surprising, a lot of the cycles are spent in inter-thread communication ping-pong (GDBus is using a private worker thread for reading/writing). Also looks like creating/destroying GMainContext objects are really expensive...
Bug 652650 (which is concerned with raw serialization performance) is related to this. Apart from raw serialization, there's still a couple of places where we can optimize GDBus - for example, its heavy use of GMainContext. For example, g_dbus_connection_send_message_with_reply_sync() right now creates a GMainContext - we could change this so it just blocks on a condition/mutex pair. Then again, I've still not seen any real complaints about GDBus performance (despite mentioning contributing on this bug every time someone complains) so this work isn't really high priority. But to repeat myself, there's absolutely no reason we can't be just as fast (or slow) as libdbus-1 if we really want to.
I'm going to repurpose this bug as a tracker bug for various GDBus optimizations.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/370.