IMPORTANT: This article is being preserved for historical purposes and likely no longer reflects the state of AT-SPI over D-Bus.
DBus and ORBit Benchmarking
AT-SPI test suite
To investigate the performance of D-Bus and ORBit a test setup was run that consisted of:
- 18000 calls to getRole - Type signature: int out
- 18000 calls to _get_parent - Type signature: object reference out
- 18000 calls to getRelationSet - Type signature: object reference array out - 10 object references passed in array.
An Orbit server was set up using the 'C' ORBit bindings. The ORBit client used the python ORBit bindings.
The D-Bus server and client did not use the accessibility IDL, but XML that best represented the three method calls. In the case of an Object reference we decided that in D-Bus the type signature (so) or a struct of string and object path best described an object reference. The string includes either a bus name or a connection method to the D-Bus server. The server was written directly to the libdbus API, the client was written using the python D-Bus bindings.
It is possible to run D-Bus in a number of configurations, either passing messages through a bus, or via a direct connection. The performance of both of these configurations was measured.
Measurements made on: Lenovo T43, 1.6Ghz Centrino processor, 512Mb ram.
ORBit |
|
Method name |
Time (Seconds) |
getRole |
0.884073 |
_get_parent |
1.652570 |
getRelationSet |
9.616625 |
D-Bus (Bus connection) |
|
Method name |
Time (Seconds) |
getRole |
4.878400 |
_get_parent |
4.889741 |
getRelationSet |
6.454061 |
D-Bus (Direct connection) |
|
Method name |
Time (Seconds) |
getRole |
2.836225 |
_get_parent |
2.791371 |
getRelationSet |
4.359469 |
Frank Duignan's test suite
The D-Bus tests made use of the glib bindings on both the client and server side. They were using the session bus rather than a direct connection. The ORBit tests used the 'C' bindings on both client and server. No modification was necessary to the code available at http://eleceng.dit.ie/frank/rpc/. All calls were made a total of 10000 times.
Retested results
D-Bus |
|
Method signature |
Time (Seconds) |
void_call |
2.390943 |
in_int_call |
2.436619 |
out_int_call |
2.438046 |
in_out_int_call |
2.632276 |
in_string_call |
2.485796 |
out_string_call |
2.497369 |
in_out_string_call |
2.701414 |
ORBit |
|
Method signature |
Time (Seconds) |
void_call |
0.526466 |
in_int_call |
0.368717 |
out_int_call |
0.372831 |
in_out_int_call |
0.374876 |
in_string_call |
0.378888 |
out_string_call |
0.389242 |
in_out_string_call |
0.388558 |
Original Reults - Taken from "CORBA, DCOP and DBUS. A performance comparison"
Frank Duignan - D-Bus |
|
Method signature |
Time (Seconds) |
void_call |
9.783550 |
in_int_call |
10.469005 |
out_int_call |
10.399278 |
in_out_int_call |
11.162058 |
in_string_call |
10.510298 |
out_string_call |
10.455126 |
in_out_string_call |
11.239133 |
Frank Duignan - ORBit |
|
Method signature |
Time (Seconds) |
void_call |
0.626480 |
in_int_call |
0.629227 |
out_int_call |
0.660020 |
in_out_int_call |
0.686850 |
in_string_call |
0.650098 |
out_string_call |
0.730118 |
in_out_string_call |
0.682283 |
Message size tests
Tests were performed on a purely synthetic method call that took an int - size, and returned an array of int of that size. The size of the message was then varied, and 2000 calls made at each different size.
The two graphs below both show time taken to make 2000 calls in seconds, against the message size in kB. The latter graph is showing a smaller range of message sizes.
It is unlikely that any messages passed over D-Bus or ORBit will be as large as the ones in these tests. D-Bus is generally quicker at passing a large array of fixed types, and this may indicate larger messages in general. The Python D-Bus bindings perform extremely poorly in this test, and its likely that there is an issue with the way they deal with de-marshalling large fixed arrays. The point at which D-Bus becomes faster than ORBit is around 4kb. D-Bus seems to have a higher overhead than ORBit per message call, but could scale better with message size.
At around 120kB message size libdbus hits a performance wall. I am unable to explain this behavior. Its likely never been an issue as message sizes of this magnitude are extremely rare / non-existent.