DBus-Daemon Optimizations
Avery Pennarun
apenwarr at gmail.com
Fri Feb 27 14:36:39 PST 2009
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
> 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.
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,
Avery
More information about the dbus
mailing list