DBus-Daemon Optimizations

[Schmottlach, Glenn]

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

http://lists.freedesktop.org/archives/dbus/2007-October/008809.html

I disabled all assertions and checks and changed the mode to
DBUS_VALIDATION_MODE_WE_TRUST_THIS_DATA_ABSOLUTELY in the source and
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

Hi,

I haven't looked at it in years but here is what I found years ago:
http://lists.freedesktop.org/pipermail/dbus/2004-November/001779.html

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
   (DBUS_VALIDATION_MODE_WE_TRUST_THIS_DATA_ABSOLUTELY, must be
   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
locking

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.

Havoc