Thanks for you reply. So you say that the best I could gain would be 30-40%. Do you think it is a bad idea today to use the very old version of DBus used here ? <a href="http://lists.freedesktop.org/pipermail/dbus/2004-November/001779.html">http://lists.freedesktop.org/pipermail/dbus/2004-November/001779.html</a> Too much bugs, API no more compatible ... ? Jerome <div class="gmail_quote">2008/11/4 Havoc Pennington <<a href="mailto:hp@pobox.com">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 class="Ih2E3d"> On Tue, Nov 4, 2008 at 6:09 AM, Jerome Philbert <<a href="mailto:jerome.philbert@gmail.com">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>