About performance of D-Bus

Kalle Vahlman kalle.vahlman at gmail.com
Tue Nov 4 11:08:13 PST 2008

2008/11/4 Kalle Vahlman <kalle.vahlman at gmail.com>:
> 2008/11/4 Jerome Philbert <jerome.philbert at gmail.com>:
>> 100ms / 4.7ms = 21 messages only
>> Moreover, this is the ideal case where the CPU has nothing else to do than
>> sending messages ...
>> In the reality, the CPU has lots'of things to do, so I could never send up
>> to 21 messages.
> For future reference:
> Intel Core 2 Duo @ 4GHz, D-Bus 1.0.2
> ** (process:26770): DEBUG: 100000 calls in 15.4960s, 6453.277708 calls/s
> ARM Cortex-A8 @500MHz (BeagleBoard), D-Bus 1.1.20
> ** (process:5637): DEBUG: 100000 calls in 122.5924s, 815.711205 calls/s
> ARM9 @ (I think) 220MHz (Nokia 770), D-Bus 1.1.20
> ** (process:1654): DEBUG: 100000 calls in 413.5156s, 241.828831 calls/s
> The test is to send synchronously an empty method_call to the service
> which replies with an empty method_reply.
> That's quite many more than 21,

Heh, of course I now notice it was about how many in 100ms... So
something little over 20 is accurate indeed.

> though granted that the numbers are
> from a idle machine. I'll try sending ints and strings as payload
> next, let's see what happens.

So now we pack arguments to the message in the client, and the service
transfers those arguments to the reply message before sending it back.

With just INT32 argument:

** (process:8797): DEBUG: 10000 calls in 43.7266s, 228.693941 calls/s


** (process:9450): DEBUG: 10000 calls in 43.6882s, 228.894911 calls/s

With both:

** (process:9624): DEBUG: 10000 calls in 49.1162s, 203.598639 calls/s

With those above plus an array of 256 doubles:
(this will already be non-optimal case since the array transfer is
done element-by-element in the service code...)

** (process:1057): DEBUG: 10000 calls in 98.8017s, 101.212807 calls/s

So that's quite a hit already.

With all of the above and a dict with two entries of string keys and
the 256 array of doubles as values (ie. '{sad}'):

** (process:4016): DEBUG: 10000 calls in 199.2698s, 50.183210 calls/s

Again the speed seems to be halved.

So no, you can't update the mouse pointer from coordinates in a hash
table through D-Bus. For real use cases though, a worst case scenario
of 5 per 100ms seems to me like it would be enough to get a decent
response time even if there would be some other messaging going on at
the same time...

I don't have a profiler handy, so I'll leave finding out where the
time is spent for another day.

Kalle Vahlman, zuh at iki.fi
Powered by http://movial.fi
Interesting stuff at http://sandbox.movial.com
See also http://syslog.movial.fi

More information about the dbus mailing list