Re: [GNUnet-developers] DBus in GNUnet?

[Christian Grothoff]

On 11/07/2013 10:26 PM, Milan Bouchet-Valat wrote:
> 
> 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.

Well, we do NOT assume that the clients can be trusted with respect
to sending well-formed data, so that part over the overhead is fine.

> 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.

Ouch, that data looks VERY bad for DBus -- worse than expected for the
CPU (3x), but catastrophic in terms of memory use.  Now, they write
that DBus "had" to allocated memory for the "entire" 75,000 rows before
sending it (which I don't quite understand), so this might be unfair.
However, we do of course have situations where we send one query and
get a large number of results back, and that should not cause 100 MB
memory use...

> 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.

Well, if the idea of a 'translator' works out, then we could have our
cake (fast UNIX-based IPC) and eat it too (elegant DBus interfaces,
expecially for non-C bindings).  But I worry that this translator
idea is likely easier said than done...

My 2 cents

Christian