what dbus performance issue could prevent it from embedded system?

Question

From my reading dbus performance should be twice slower than other messaging ipc mechanisms due to existence of a daemon.

In the discussion of the so question which

Answer 1

Well, the Genivi alliance, targeting the automotive industry, implemented and supports CommonAPI, which works on top of DBUS, as IPC mechanism for cars' head-units.

Answer 2

I don't think there is any real-and-big performance issue.

Did some profiling:

• On an arm926ejs 200MHz processor, a method call and reply with two uint32 arguments consumes anywhere between 0 to 15 ms. average 6 ms.

• Changed the 2nd parameter to an array of 1000 bytes. If use the iteration api to pack and unpack the 2nd parameter, it takes about 18 ms.

• The same 2nd parameter of an array of 1000 bytes. If use the fixed-length api to pack and unpack the 2nd parameter, it takes about 8 ms.

• As a comparison, use the SysV msgq passing a message to another process and getting a reply. It is about 10 ms too, though without optimizing the code and repeating the test for a large number of samples.

In summary, the profiling does not show a performance issue.

To support this conclusion, there is a performance related page on dbus page, which specifies only the double-context-switching because with dbus it needs to pass the message to the daemon then to the destination.

Edit: If you send messages directly bypassing the daemon, the performance would double.