DBus-Daemon Optimizations

[Schmottlach, Glenn]

I disabled validation in the D-Bus library by hard-coding 

mode = DBUS_VALIDATION_MODE_WE_TRUST_THIS_DATA_ABSOLUTELY;

in dbus-message.c. From what Havoc has said (at least in the past), this
*should* disable the bulk of the validation logic. Likewise, I've turned
off API checks and assertions. For my simple test case on the Beagle
Board, the above actions save me roughly 2 msec in round-trip time. At
10 msec per call (down from 12 msec), it's still not the number I was
looking for. In the embedded world, that's enough to make most
developers cringe . . . even more so on a "high-end" embedded processor
like the TI OMAP 3530 (500 MHz). Perhaps this overhead isn't even
noticed on a multi-core, 2+ GHz Pentium where D-Bus was originally
intended to be used (since it is an application bus). I was hoping that
with a little tweaking and some consideration for performance improving
measures, there might be an opportunity to leverage it more effectively
in the embedded space. Certainly, with the rise of connected embedded
Linux devices, this could be a huge market that ultimately eclipses the
desktop.

Perhaps the mailing-list lurkers out there already using D-Bus on an
embedded platform could chime in with their experiences, offer any
optimization techniques, or provide real-world performance statistics on
their platforms. I wonder if I am alone in seeing these rather dismal
round-trip access times.




-----Original Message-----
From: dbus-bounces at lists.freedesktop.org
[mailto:dbus-bounces at lists.freedesktop.org] On Behalf Of Havoc
Pennington
Sent: Sunday, March 01, 2009 11:39 PM
To: Thiago Macieira
Cc: dbus at lists.freedesktop.org
Subject: Re: DBus-Daemon Optimizations

Hi,

On Sun, Mar 1, 2009 at 4:03 PM, Thiago Macieira <thiago at kde.org> wrote:
> You're correct: the daemon unmarshalls, validates and remarshalls the
> messages passing through it. If the incoming message is invalid in any
> shape or form, it will disconnect the sender and discard the message.
>

I'm pretty sure that isn't *quite* true; in particular I'm not sure
it's right to say it unmarshals and remarshals. It should be getting a
DBusMessage object off the wire and then writing the same DBusMessage
object to the recipient. It's true that it does a fair bit of
validation in converting the incoming bytes to a DBusMessage, but
DBusMessage does store the bytes in marshaled form, so unless
something is broken there should not be an unmarshal/remarshal.

There is some modification of the message (adding more headers, such
as sender) so that could have some cost. One possible optimization is
to have the sender client include the sender header to begin with and
then the bus would just check it. But, doubtful that's a big win.

Bottom line, would need to start with some profiling. Pretty obvious I
guess.

Best I remember, the validation and marshaling code just isn't that
fast. I remember more a constant-factor distributed-bloat problem than
a fundamental design problem like extra copies. But, if nobody has
profiled lately, for all we know some really bad f-up has been
introduced in the last few years accidentally. In the past, there have
been things like reparsing /etc/group on every message... you never
know until you profile.

Havoc
_______________________________________________
dbus mailing list
dbus at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dbus