Re: [GNUnet-developers] DBus in GNUnet?

[Milan Bouchet-Valat]

Le jeudi 07 novembre 2013 à 11:53 +0100, Christian Grothoff a écrit :
> I don't like having two ways to do things in the code, so this would
> have to be done with the goal of replacing UNIX with DBus entirely
> eventually.  Because of that, I'd really like to see
> 
> * better understanding of the group access control issue
> * performance evaluation (memory overhead, CPU impact);
>   i.e. we could compare creating 100,000 IPC channels and
>   between 4,000 processes and sending 10,000,000 messages
>   (of different sizes, say 4-32k bytes, in both directions
>   query-response style).
> * some sample modifications for client and service code (i.e. for
>   just the DHT service)
> 
> If that all looks good, I think you might have a convincing
> argument to me (and the other developers!).  But if the
> performance is bad (on the CPU, I might be OK with 2x if the
> code is significantly nicer, but on memory, 2x would totally
> not be acceptable).
> 
> I hope you understand why I'm not just giving you a green light
> on this --- this would really be a major change and I'd really
> want to be sure that this is the right direction.
I really like D-Bus as a general RPC mechanism, but I don't think it is
intended as an efficient way of passing large amounts of data
intensively. In particular there's a lot of marshalling involved and
that's quite expensive. If you know (or can assume) that you can
trust the clients, then you will get a major speed gain with a custom
protocol.

>From the D-Bus FAQ:

> How fast is the D-Bus reference implementation?
> 
> 
> Of course it depends a bit on what
> you're doing. This mail contains
> some benchmarking. At the time of
> that benchmark, D-Bus one-to-one
> communication was about 2.5x slower
> than simply pushing the data raw
> over a socket. After the recent
> rewrite of the marshaling code,
> D-Bus is slower than that because a
> lot of optimization work was lost.
> But it can probably be sped up
> again. 
> 
> D-Bus communication with the
> intermediate bus daemon should be
> (and as last profiled, was) about
> twice as slow as one-to-one mode,
> because a round trip involves four
> socket reads/writes rather than two
> socket reads/writes. 
> 
> The overhead comes from a couple of
> places; part of it is simply
> "abstraction penalty" (there are
> layers of code to support multiple
> main loops, multiple transport
> types, security, etc.). Probably
> the largest part comes from data
> validation (because the reference
> implementation does not trust
> incoming data). It would be simple
> to add a "no validation" mode, but
> probably not a good idea all things
> considered. 
> 
> Raw bandwidth isn't the only
> concern; D-Bus is designed to
> enable asynchronous communication
> and avoid round trips. This is
> frequently a more important
> performance issue than throughput. 
> 
> 


Also, Tracker did some research and eventually moved away from D-Bus for some
cases:
http://pvanhoof.be/blog/index.php/2010/05/13/ipc-performance-the-report

If in doubt, you could ask on their mailing list.


That said, D-Bus interfaces would still be useful to make it easy for
applications written in any language to access high-level API, i.e.
operations that do not require too much exchange of data between
processes. For example, starting a file download, getting the list of
known peers and even chatting would work very well other D-Bus.


My two cents