About performance of D-Bus

[Havoc Pennington]

Hi,

On Fri, Oct 31, 2008 at 9:15 AM, Havoc Pennington <hp at pobox.com> wrote:
> I am not saying that dbus is only 2% of the time; maybe on your
> embedded device it is more time. I don't know. But you should profile
> this before you bother trying to improve dbus. Because if dbus is 2%
> of the time, you should work on the other 98%, not on dbus.
>

And the other point is to look at how dbus is used.

If dbus is 50% of the time for some user action, there's a good chance
you are using dbus in a bad way, e.g. making dozens of round-trip
calls to implement a single user action.

Doubling dbus speed could get you from 50% of the user action spent in
dbus, to 25% of the user action spent in dbus.

But fixing how dbus is used, e.g. removing the misdesigned
round-trip-requiring APIs, could get you from 50% of user experience
time in dbus, to 1% of user experience time spent in dbus. Which is a
much bigger win.

The bottom line is that there just aren't that many real world
contexts where the time it takes to make a dbus method call is any
kind of bottleneck. You have to make 1000 method calls to create a
bottleneck, not 1. So, frequently, optimization involves reducing the
number of calls, not making the calls faster.

Once again, I am not *against* optimizing dbus. Please give it a shot.
I am just trying to be helpful - if you have an actual *product* with
a user experience that covers a lot of non-dbus stuff, you should not
spend your time optimizing dbus unless you *know* dbus is the problem.

Havoc