OT: Is ORBit still faster than DBus?

while I don't think 17x is accurate, libdbus is certainly slower than orbit. it's inherently slower by 2x, because of the bus - all apps go to a bus process then to other apps, so messages go over two sockets - of course, this also adds a lot of features, so it is worth it. but libdbus is also just plain slower even if you ignore that. it's coded with priorities other than speed.

however, gnome 3 will mostly use the new gdbus implementation in glib, which may well be faster than libdbus. however, it's still unlikely to be faster than orbit. orbit was fast, but didn't have the right features.

all this said, afaik libdbus has never been seriously optimized (or at all optimized) since this effort in 2004:
http://lists.freedesktop.org/pipermail/dbus/2004-November...
and that 2004 effort was largely ruined when arbitrary recursive types were added to libdbus later on, which rewrote a bunch of the code.
See also http://log.ometer.com/2006-07.html#21

gdbus may still need profiling and tuning, or someone may have already done it, I have no idea.

I think the reason libdbus hasn't been seriously optimized is that it rarely shows up in profiles unless someone is doing something idiotic. It's common on Slashdot or whatever to assume that X is slow due to IPC, or GNOME is slow due to CORBA, or whatever, but the reality is that I've never seen IPC near the top of a profile for a desktop app, unless the app was doing something fundamentally bad that experienced desktop programmers know to avoid these days.

The rules are pretty simple for both X and dbus, for example:
* don't make blocking round trips where you wait for IPC to complete and lock up the whole app
* design the out-of-process interface to avoid round trips and to avoid "too much" IPC
* use shared memory if you're going to shovel some giant block of data (though unix domain sockets are so fast, this is less important than one might think)

If you plan things so you have dozens or a hundred IPC calls instead of thousands, and don't have to block for call 1's result in order to make call 2, you'll be fine. One advantage of dbus is that it has a lot of features designed to *avoid* the need to block in a round trip, and the new gdbus API has some nice features to help apps avoid this.

I think server-side programmers often have the wrong intuition here, because of course IPC is going to be a bottleneck for server apps that are mostly about handling network requests. But desktop apps mostly spend their time drawing pixels or waiting for mouse events or waiting on the filesystem or any number of things, while their use of IPC is just a few messages here and there. Also, desktop IPC is unix domain sockets, which are just elaborate cross-process memory copies. This is pretty different from TCP.

A historical issue was the idea of using IPC for a "component system" so that an app could be made up of a swarm of different processes; that architecture would indeed tend to bottleneck on IPC. However, it was a bad idea and a lot of the design of dbus was done with this use-case specifically excluded. The modern GNOME equivalent of "component system" in this sense would be GObject plus gobject-introspection, an in-process setup.

I'm sure profiling (and optimizing based on said profile) libdbus and gdbus would be a fun project, and welcome. But I don't know if there's anything that would be user-visibly faster in GNOME afterward.