DBus-Daemon Optimizations

Schmottlach, Glenn glenn.schmottlach at harman.com
Fri Feb 27 14:25:16 PST 2009

Thanks for the feedback. I also found this thread later:


I disabled all assertions and checks and changed the mode to
re-compiled. This ended up saving me ~ 2 msec on my simple test (went
from 12 msec to 10 msec). Obviously there is some improvement, but
certainly not what I was hoping for. I guess it would be interesting to
see how much overhead the locking incurs . . . but I suspect that's not
the ultimate culprit.

-----Original Message-----
From: Havoc Pennington [mailto:havoc.pennington at gmail.com] 
Sent: Friday, February 27, 2009 5:20 PM
To: Schmottlach, Glenn
Cc: dbus at lists.freedesktop.org
Subject: Re: DBus-Daemon Optimizations


I haven't looked at it in years but here is what I found years ago:

I don't know if I've seen much analysis of dbus performance since
then. One might assume that dbus is not showing up as the bottleneck
in very many real-world situations, but maybe people are just quiet
about it.

*after* those 2004 profiling numbers, dbus was changed to support a
fully general recursive type system, which slowed it down a bit again.

The quick tips are:
 * be sure you don't have assertions or debug logging turned on
 * try disabling message validation if your dbus doesn't deal with
untrusted data
   changed in the source where DBUS_VALIDATION_MODE_DATA_IS_UNTRUSTED
   is currently hardcoded)
 * if you aren't using threads you might be able to hack out the thread

Otherwise afaik it's just that there's a fair bit more code running
than would be running if you were using raw sockets. It is not highly
optimized for speed.


More information about the dbus mailing list