About performance of D-Bus

[Havoc Pennington]

Hi,

On Fri, Oct 31, 2008 at 8:36 AM, Diego Jacobi <jacobidiego at gmail.com> wrote:
> just to note.
> With "nobody" you are excluding me, a user of low-end pcs and Jerome
> Phillbert too, a user of embedded devices.
>

I am not. What I'm saying is that if, *hypothetically*, dbus is 2% of
the time in your overall user-experienced time, then if you make dbus
twice as fast, that is a 1% speedup in what users experience, which is
simply not noticeable. If I did an A-B test on you, you would not be
able to see that difference.

The low-endness of your PC is irrelevant; maybe 100% of the time is
longer on a low-end PC, but the percent of total that is dbus should
be the same.

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.

I do think that dbus is probably 2% of the time or something like that
on a typical desktop session - and this would be true on low-end PCs
too, since the CPU speed will only change the absolute times not the
relative times.

Most of the slow in GNOME for example tends to be disk I/O. But, I
have not recently profiled it. Maybe dbus is more these days.

But you'd be silly to blame dbus without profiling the entire user
experience. If you just profile dbus, you don't know if dbus even
matters.

Anyone is more than welcome to optimize dbus. But, what I'm saying is
that they would be stupid to do so without first establishing that
optimizing dbus will be visible to their users by profiling the
*entire* user experience, not just dbus.

Havoc