DBus-Daemon Optimizations

[Matt Hoosier]

I've worked on several projects that use D-Bus (system daemon, if you care)
for commercial embedded consumer electronics. Throughput hasn't really been
a problem, but we have tended to use it for control/business-logic
messaging, not as a high-throughput data path.

--Matt

On Mon, Mar 2, 2009 at 9:48 AM, Schmottlach, Glenn <
glenn.schmottlach at harman.com> wrote:

> 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
>
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/dbus/attachments/20090314/bf6aa471/attachment.html