Thanks again for your analysis, Havoc. Finally, your suggestions for optimizing speed, consist in removing security and check from DBus, what is contrary to the interest of D-Bus, especially if it is designed for an open platform. But I cannot have both speed and security :-) I think I have also tried your suggestions number 3 and 4. Is not it equivalent to: - remove paranoid validation ? (by using DBUS_VALIDATION_MODE_WE_TRUST_THIS_DATA_ABSOLUTELY in the code) - build D-Bus with disable-checks option ? In this way, I have measured that D-Bus was 7% faster. Jerome <div class="gmail_quote">2008/11/4 Havoc Pennington <<a href="mailto:hp@pobox.com" target="_blank">hp@pobox.com</a>> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi, <div> On Tue, Nov 4, 2008 at 6:09 AM, Jerome Philbert <<a href="mailto:jerome.philbert@gmail.com" target="_blank">jerome.philbert@gmail.com</a>> wrote: > 100ms / 4.7ms = 21 messages only > Moreover, this is the ideal case where the CPU has nothing else to do than > sending messages ... > In the reality, the CPU has lots'of things to do, so I could never send up > to 21 messages. > </div>On a CPU this slow, it isn't clear that libdbus is remotely usable; you may need a dbus implementation (or other ipc system) that is making different tradeoffs in the direction of efficiency. Or worst-case, you may need to figure out how to avoid some of the ipc. If you made a dbus library that: * always blocked, thus eliminating the need to build DBusMessage objects or maintain a message queue or deal with main loop * was not thread-safe, thus eliminating locking * was not robust against hostile peers, thus eliminating message validation * did not ever do checks like dbus_return_if_fail thus eliminating more code * was not safe against out-of-memory, thus eliminating even more code * did not try to "multiplex" code modules with "path registration" or "handler registration", thus killing more code and overhead I think you could have a library that was dramatically smaller and faster, fwiw. Basically by making it much less flexible and robust, and just being careful about using it. I believe an implementation of dbus could be pretty close to raw socket speed by making tradeoffs like the above. Current libdbus I'm sure can be made 30% faster or 40% faster or something like that, given enough effort, but if you are only getting 21 messages now, then even a 100% speedup would only get you to 42 messages. If that still won't be enough, I would not dive into libdbus optimization, I would figure out how to somehow use dbus less. Again, we'd definitely love to see someone work on making current libdbus faster. Havoc </blockquote></div>