DBus-Daemon Optimizations

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

I'm not even attempting to match QNX's native messaging speed. It would
be like comparing apples to oranges. QNX's native services are a very
low-level transport that lacks all the bells-and-whistles that DBus
offers. Of course that comes at a price . . . an apparently significant
one. I was hoping to achieve > 1msec round-trip times. Looks like that
may be beyond my grasp without a lot of work.

-----Original Message-----
From: Avery Pennarun [mailto:apenwarr at gmail.com] 
Sent: Friday, February 27, 2009 5:37 PM
To: Schmottlach, Glenn
Cc: dbus
Subject: Re: DBus-Daemon Optimizations

On Fri, Feb 27, 2009 at 5:25 PM, Schmottlach, Glenn
<glenn.schmottlach at harman.com> wrote:
> 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
> 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
> see how much overhead the locking incurs . . . but I suspect that's
> the ultimate culprit.

You should keep in mind that you're comparing dbus, which is not at
all speed-optimized, with what is probably one of the very fastest
message-passing systems in the entire world, consisting of
hand-optimized assembly and assisted by a hand-optimized kernel.

If I understand correctly, message passing in QNX involves
transferring approximately one *pointer* (4 bytes) plus a length and
maybe a tiny amount of other data like flags.  The data itself is
never even copied, AFAIK.  My information is a few years old, but I
heard QNX doesn't even have a default message "queue"; just a single
message pointer per process, because a queue is "too much overhead."

Anyway, that's just some background.  It's not very surprising to me
that QNX would have absurdly fast message passing.  It would be great
if DBus could approach that kind of speed, but it's going to be a lot
of work.

Have fun,


More information about the dbus mailing list