About performance of D-Bus
tian tian
mr.zoufeng at gmail.com
Fri Oct 26 00:33:09 PDT 2007
Many thanks for all these advices.
I did some more tests today. As Havoc's advice, I changed the code:
mode = DBUS_VALIDATION_MODE_DATA_IS_UNTRUSTED;
to
mode = DBUS_VALIDATION_MODE_WE_TRUST_THIS_DATA_ABSOLUTELY;
, then re-compile D-Bus V1.0.2 with:
./configure --host=arm-linux
--with-xml=expat
--without-x
--disable-tests
--disable-verbose-mode
--disable-asserts
--disable-checks
make install
And the test program is:
client
gettimeofday() /* -> timer1 */
dbus_message_new_method_call()
dbus_message_append_args()
dbus_message_set_no_reply()
dbus_connection_send()
dbus_connection_flush()
gettimeofday() /* -> timer2 */
gettimeofday() /* -> timer3 */
dbus_message_new_method_call()
dbus_message_append_args()
dbus_connection_send_with_reply_and_block()
gettimeofday() /* -> timer4 */
server
dbus_filter()
{
gettimeofday() /* -> timer5 */
}
Results(data unit is "byte", time unit is "microsecond"):
input output timer1 timer2 timer3 timer4 timer5
---------------------------------------------------------------------------------------
0 0 0 2260 - - 1336
0 0 - - 0 462 1987
100 0 0 2741 - - 1701
100 0 - - 0 573 1991
100 100 0 2826 - - 1547
100 100 - - 0 462 3647
I'am glad to see it works much better. Nevertheless, I want it can
complete a synchronous remote call in several hundreds microseconds(at least
< 1500 microseconds). And it is more slower(about 1.3x) if I use the
bus-daemon.
I have noticed that D-Bus is designed to enable asynchronous
communication and avoid round trips, but I hope to use this useful message
bus system in my embeded system. In this system, there are synchronous
remote calls as many as asynchronous calls. That's why I care about the
performance of D-Bus greadtly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/dbus/attachments/20071026/97f7512d/attachment.htm
More information about the dbus
mailing list