DBus performance with file-data / thoughts on a future VFS

As Gnome-VFS has switched to D-Bus - and some modules (like SMB) use D-Bus to transport file-data i would like to raise the question if D-Bus is a good choice for this purpose...

Here is a comparison of D-Bus with a simple IPC message protocol (vio_trans*)), sending 1 GB of data with one-way messages (4096 byte data chunks) over sockets (from client to server)...

16.60user 2.10system 1:16.05elapsed 24%CPU
49.39user 2.93system 1:18.58elapsed 66%CPU

0.38user 2.08system 0:06.70elapsed 36%CPU
0.52user 2.01system 0:09.76elapsed 26%CPU

--> D-Bus is more than 10 times slower. Of course D-Bus performance for byte-arrays could be improved, but the protocol overhead will remain. I guess D-Bus is just not optimal for this particular purpose...

How I tested:

client test:
$ dd if=/dev/zero bs=1000000000 count=1 | time vio_trans_streamtest client /tmp/testsock

server test:
$ time vio_trans_streamtest server /tmp/testsock | wc -c

A simple IPC protocol specially designed for VFS file-operations could be pretty fast. Perhaps all protocol-handlers could run inside the VFS daemon and the clients connect via a socket. It's easier to provide an async client interface this way - you don't need threads in the client...

Also, the VFS client library can be pretty lightweight, perhaps event without a glib dependency and therefore be more attractive to be used by everyone (even KIO?). Another advantage of moving protocol handling to a daemon is that buggy protocol handlers cannot crash the client application...

In the VFS-daemon there would be one thread per client connection. Because protocol-handlers (modules) are synchronous, the client has to open multiple connections for concurrent file-operations...

*) The vio_trans library and the tests can be downloaded from here:


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]