Performance of DBUS with multiple nodes
Jacques Guillou
jacques.guillou at gmail.com
Thu Mar 29 06:46:27 PDT 2007
Thanks for your answer.
If the daemon doesn't keep any introspection data, I guess that also means
it doesn't check message signatures against the corresponding introspection
data, right ?
So you can call a method with "wrong" parameter types without being rejected
by the daemon (probably the service itself will fail somehow) ?
But if you try to extract an integer from a message which actually contains
a string, you will get an error, probably by the binding and not by the
daemon ?
So the daemon doesn't perform any check on the content of the messages, does
it ?
Jacques
On 3/29/07, Havoc Pennington <hp at redhat.com> wrote:
>
> Hi,
>
> Jacques Guillou wrote:
> > The questions :
> > Does the DBus forwarding performance decrease when many nodes are
> > registered to the bus ?
>
> I'm assuming by "node" you mean object path?
>
> If you mean bus name, then there is probably some performance
> implication to having thousands of them, yes. I don't know how bad it
> would be. I don't think it will be O(n) but maybe something is - if so
> it could be fixed. It may use memory though.
>
> If you mean object path, then those are not registered by the bus at
> all, so there's zero impact on the bus.
>
> There are two ways to do object paths with libdbus:
> - register each one separately with DBusConnection; in this case, each
> one will use memory
> - register a handler for your "subtree" with DBusConnection, which
> will use one fixed small amount of memory; then parse the rest of the
> object path after the common prefix yourself - this should be efficient
> up to any number of object paths, as long as your app code is efficient
>
> > What about the memory usage ? Is the introspection data stored for each
> > node in the daemon itself or is it accessed on demand ?
>
> Introspection data is never kept around by libdbus or dbus-daemon
>
> For all of the above, there may be issues specific to the language
> binding you are using, in addition to the raw libdbus/dbus-daemon answer.
>
> Havoc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/dbus/attachments/20070329/e3325283/attachment.html
More information about the dbus
mailing list