|
|
Subscribe / Log in / New account

OT: Is ORBit still faster than DBus?

OT: Is ORBit still faster than DBus?

Posted Jul 29, 2010 8:39 UTC (Thu) by debacle (subscriber, #7114)
In reply to: OT: Is ORBit still faster than DBus? by hp
Parent article: GNOME 3.0 release delayed

Many thanks for your insightful explanation! I have to learn about gdbus...

(My question was really off-topic, because I will use DBus in an embedded, non-graphical, non-Gnome application. We will use DBus, not CORBA, because we have to communicate with dbus apps like Network Manager etc. anyway, so it's just easier to stay with DBus, even if it's slower.)


to post comments

OT: Is ORBit still faster than DBus?

Posted Jul 29, 2010 18:00 UTC (Thu) by aleXXX (subscriber, #2742) [Link] (2 responses)

It would really be a good idea if somebody (you ?) would try to optimize libdbus.
Especially embedded developers often report bad performance numbers, e.g. when running on a 200 MHz ARM or so.

One thing you can do is to use libdbus in peer-to-peer mode, this avoids visiting the bus daemon and by this one receive, deserialize, serialize, send combination. But it's more work. AFAIK no binding supports this mode currently, so you have to do it using libdbus directly.

Alex

OT: Is ORBit still faster than DBus?

Posted Jul 29, 2010 18:22 UTC (Thu) by debacle (subscriber, #7114) [Link]

ARM@200MHz is exactly our platform and we already feel the pain. Our solution will be probably the same as I would do with CORBA: Reduce the number of IPC calls. The idea of using peer-to-peer DBus sounds nice, too. In CORBA world this is the common way, using e.g. event services is the exception. Many thanks for the suggestion!

OT: Is ORBit still faster than DBus?

Posted Jul 29, 2010 18:27 UTC (Thu) by hp (guest, #5220) [Link]

dbus was designed for the desktop... I think when people try to repurpose it for embedded or other purposes, they have to be prepared to go in and make it actually work in those scenarios. I don't know anything about these use-cases, and they just were never thought about when creating dbus.

minimizing IPC and going peer-to-peer instead of through the bus are both good suggestions.

if you have simple needs just using a raw unix socket instead of a whole IPC "system" might be a good option too. for peer-to-peer the "XMLSocket" protocol that Flash uses is a nice simple one: bidirectional stream of nul-separated strings. Not a lot of code to write for that.

anyway, anyone is welcome to improve libdbus or gdbus or any of the other implementations of dbus, of course! make it do what you need. that's what open source is about.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds