D-Bus optimizations

[Alberto Mardegan]

Hi Havoc,

On 03/03/2012 12:52 AM, Havoc Pennington wrote:
> Too busy doing what, would be my first impulse to investigate here -
> what is so chatty that dbus-daemon is flooded and backlogged? Where is
> the daemon spending its CPU time when it's backlogged?

One thing which I remember causing a user-perceivable slowness on the
N900 was going online: if you had one or more chat accounts configured,
each of them was retrieving the contacts list and their online status,
avatars and capabilities; the system was certainly busy also for other
reasons, but I clearly remember seeing tons of traffic on the session
bus with dbus-monitor.

That said,

> It would just be great to have some kind of clear and measurable goal
> in mind. If the goal is "as fast as possible" / "runs on the
> lowest-end hardware we can come up with no matter what" / "as fast as
> raw sockets" then I don't know - maybe it'd be better to do some
> really simple, fast side-channel with dbus-compatible type system and
> encourage including it alongside all the dbus implementations.
[...]

this sounds like an excellent idea. It's actually possible to implement
such side channels already now (any process can register a D-Bus
server), I think that what we miss is, as you say, the possibility to
relax the protocol (optionally skip the validation?) and somehow make it
easier to setup.
However, if each service (or framework) created its own D-Bus server,
the number of connections per client might become a problem.

Ciao,
  Alberto

-- 
http://blog.mardy.it <- geek in un lingua international!