DBus-Daemon Optimizations

[Schmottlach, Glenn]

Thanks for the feedback on your experiences in an embedded platform. We too anticipate using D-Bus for control/business-logic applications as well but the latencies of the bus has raised some eye-brows from the hard-core embedded folks in my group. I've done a little profiling myself and there seems to be indications that the marshalling/unmarshalling code may be far from efficient. At this point I don't know if that's the true smoking gun, but I guess it's somewhere to start. I find it hard to believe that the large latencies are justified. Perhaps I am naive with regards to the complexity involved in the daemon.

-Glenn



-----Original Message-----
From:	dbus-bounces at lists.freedesktop.org on behalf of Matt Hoosier
Sent:	Sat 3/14/2009 5:58 PM
To:	dbus at lists.freedesktop.org
Cc:	
Subject:	Re: DBus-Daemon Optimizations

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
>