DBus performance with file-data / thoughts on a future VFS
- From: nf2 <nf2 scheinwelt at>
- To: gnome vfs list <gnome-vfs-list gnome org>
- Subject: DBus performance with file-data / thoughts on a future VFS
- Date: Mon, 24 Jul 2006 03:13:48 +0200
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:
$ dd if=/dev/zero bs=1000000000 count=1 | time vio_trans_streamtest
$ 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
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:
] [Thread Prev