About performance of D-Bus

[Jerome Philbert]

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 ?
http://lists.freedesktop.org/pipermail/dbus/2004-November/001779.html
Too much bugs, API no more compatible ... ?

Jerome

2008/11/4 Havoc Pennington <hp at pobox.com>

> Hi,
>
> On Tue, Nov 4, 2008 at 6:09 AM, Jerome Philbert
> <jerome.philbert at gmail.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/dbus/attachments/20081104/7cb8cf9a/attachment.html