[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freedesktop-dbus
Subject:    Re: About performance of D-Bus
From:       "Diego Jacobi" <jacobidiego () gmail ! com>
Date:       2008-10-31 12:36:37
Message-ID: 5de034af0810310536p3f44fc0ao57be35b5be46f034 () mail ! gmail ! com
[Download RAW message or body]

2008/10/31 Havoc Pennington <hp@pobox.com>:
> Hi,
>
> On Fri, Oct 31, 2008 at 3:37 AM, Alberto Mardegan
> <mardy@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@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.
_______________________________________________
dbus mailing list
dbus@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dbus
[prev in list] [next in list] [prev in thread] [next in thread]