About performance of D-Bus

[Diego Jacobi]

2008/10/31 Havoc Pennington <hp at pobox.com>:
> 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
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus
>

just to note.
With "nobody" you are excluding me, a user of low-end pcs and Jerome
Phillbert too, a user of embedded devices.

Diego.