Hi, On Tue, Nov 4, 2008 at 6:09 AM, Jerome Philbert 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. > 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 _______________________________________________ dbus mailing list dbus@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dbus