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 _______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
