DBus-Daemon Optimizations

[Curtis Maloney]

Schmottlach, Glenn wrote:
> 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.

Whilst lurking on this list I have seen it stated REPEATEDLY that the 
un/marshalling code has had NO effort to optimise since it was rewritten in 
the late 0.9 stages.  Pretty much every time someone talks of speeding up 
DBus, the same conclusion is reached:  Marshalling is the first place to look.

> 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.

The above situation is generally mitigated with the point that DBus is 
targeted as modern desktop usage, and in such situations is such a small 
fraction of the user experienced time, it's not worth optimising.

Now, my own use has seen dbus-daemon using up to 6% of a Xeon 3.2GHz, and I 
certainly wouldn't mind seeing some optimisations landed, but I suspect it 
will be the embedded people who will push hardest for this, as they're the 
ones who will get the greatest rewards.

The upshot of my message?  The problem is known, the target is known, and 
someone needs to take it upon themselves to do the work.  It's not enough of 
an issue for the primary targeted use of DBus for the 'core' devs to give it 
a high priority.

-- 
Curtis Maloney
cmaloney at cardgate.net