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 634471 - GDBus Optimizations
GDBus Optimizations
Status: RESOLVED OBSOLETE
Product: glib
Classification: Platform
Component: gdbus
2.33.x
Other All
: Normal normal
: ---
Assigned To: David Zeuthen (not reading bugmail)
gtkdev
Depends on: 652650
Blocks:
 
 
Reported: 2010-11-10 02:25 UTC by Mike Gorse
Modified: 2018-05-24 12:52 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Equivalent test app using libdbus. (1.13 KB, text/plain)
2010-11-10 02:27 UTC, Mike Gorse
Details
Test using gdbus. (817 bytes, text/plain)
2010-11-11 13:39 UTC, Mike Gorse
Details

Description Mike Gorse 2010-11-10 02:25:28 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
Comment 1 Mike Gorse 2010-11-10 02:27:40 UTC
Created attachment 174173 [details]
Equivalent test app using libdbus.
Comment 2 David Zeuthen (not reading bugmail) 2010-11-10 02:57:09 UTC
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
Comment 3 David Zeuthen (not reading bugmail) 2010-11-10 15:39:53 UTC
(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 4 David Zeuthen (not reading bugmail) 2010-11-10 15:40:59 UTC
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.)
Comment 5 Mike Gorse 2010-11-11 13:39:17 UTC
Created attachment 174245 [details]
Test using gdbus.

Oops--I neglected to add this when I filed the bug.
Comment 6 David Zeuthen (not reading bugmail) 2010-11-11 15:35:14 UTC
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...
Comment 7 David Zeuthen (not reading bugmail) 2011-06-15 13:58:24 UTC
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.
Comment 8 David Zeuthen (not reading bugmail) 2011-06-15 14:04:41 UTC
I'm going to repurpose this bug as a tracker bug for various GDBus optimizations.
Comment 9 GNOME Infrastructure Team 2018-05-24 12:52:01 UTC
-- 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.