About performance of D-Bus

[Havoc Pennington]

Hi,

On Fri, Oct 31, 2008 at 3:37 AM, Alberto Mardegan
<mardy at users.sourceforge.net> wrote:
> As it seems that communication via the bus daemon is 2 times slower than direct
> communication, has anyone considered having the system bus only as a register of
> running D-Bus applications/objects/interfaces, and have all the real
> communication done directly?

Having all the communication done directly would be optimizing for the
wrong thing; in a typical desktop session usage, the 2x slower does
not matter, but having a ton of extra file descriptors and complexity
as every app connects to every other app would matter a lot. If you
kept the same semantics as the current bus, a "swarm" architecture
might have enough overhead to be slow in its own right, as well, due
to some sort of complex bookkeeping, not even sure how it would work.

That said, if you have a specific use-case where for example you are
moving a large amount of data, it is encouraged to use the bus to set
up a 1-1 connection. libdbus does support 1-1 connections (create a
DBusServer to listen on a socket in one process, then connect to it
from another, sending the server address over the bus).

But, this extra out-of-band channel is rarely needed; the bus is
perfectly fast enough for all the typical stuff you might do in a
desktop session.

Before optimizing dbus the first question is always "how much of my
overall user experience time is spent in dbus?" and at least for the
intended uses of dbus (desktop sessions, systemwide bus) the answer
has usually been "not much" which (I think) is why nobody has spent a
lot of time sending in optimization patches. Making dbus take up 1% of
your user experience instead of 2% is a huge dbus speedup that would
be a lot of work, but nobody would ever notice.

Another thing to keep in mind is that if your app is doing round trips
(blocking on one message reply before sending the next message) that
is going to kill you, vs. sending batches of messages and then getting
all their replies later. One of the design goals of dbus was to allow
you to avoid these blocking round trips. If you force each message to
have a reply before sending the next one, then that is quite a lot
slower. Often this is an API design issue, for example, avoid APIs
where you have to get thing A, then from A get B, then from B get C,
because you'll have to wait for each get to return before calling the
next one. A better design, for example, would return A+B+C all at once
from a single method call. That will be much more than 3x faster,
because 3 blocking round trips is much slower than 3 "pipelined"
method calls. It is the same principle as http pipelining:
http://www.mozilla.org/projects/netlib/http/pipelining-faq.html

Havoc