什么dbus性能问题可以阻止它嵌入式系统？

Question

从我的阅读中看，由于存在守护进程，dbus性能应该比其他消息传递ipc机制慢两倍。

在讨论这样的问题which Linux IPC technique to use时，某些人提到了性能问题。除了两倍慢的因素外，您是否看到性能问题？您是否看到阻止dbus在嵌入式系统中使用的问题？

据我所知，dbus是否适用于小消息。如果需要传递大量数据，其中一个解决方案是将数据放入共享内存或堆中，然后使用dbus进行通知。根据所讨论的其他ipc机制正在考虑的是：信号，匿名管道，命名管道或FIFO，SysV消息队列，POSIX消息队列，SysV共享内存，POSIX共享内存，SysV信号量，POSIX信号量，FUTEX锁，文件 - 支持和匿名共享内存使用mmap，UNIX域套接字，Netlink套接字，网络套接字，Inotify机制，FUSE子系统，D-Bus子系统。

我应该提到another so question which lists the requirements（尽管它以apache为中心）：

• 包/消息导向
• 处理点对点和一对多通信的能力
• 没有层次结构，没有服务器和客户端
• 如果一个端点崩溃，则必须通知其他端点
• 来自现有Linux发行版的良好支持
• 为了创建动态页面而存在Apache的“绑定” - 这太具体了，在一般的嵌入式dbus使用讨论中可以忽略它

然而another so question about performance提到了改善表现的技巧。有了这一切，我想在嵌入式系统中使用dbus时应该有更少的问题或缺点。

Answer 1

我认为没有任何实质性和性能问题。

做了一些分析：

• 在arm926ejs 200MHz处理器上，方法调用和两个uint32参数的回复消耗0到15毫秒之间的任何值。平均6毫秒。

• 将第二个参数更改为1000个字节的数组。如果使用迭代api打包并解压缩第二个参数，则需要大约18毫秒。

• 1000字节数组的第二个参数。如果使用固定长度的api打包并解压缩第二个参数，则大约需要8 ms。

• 作为比较，使用SysV msgq将消息传递给另一个进程并获得回复。它也是大约10毫秒，但没有优化代码并重复测试大量样本。

总之，分析不会显示性能问题。

为了支持这一结论，dbus页面上有一个与性能相关的页面，它只指定了双上下文切换，因为dbus需要将消息传递给守护进程然后传递到目的地。

编辑：如果你send messages directly bypassing the daemon，表现会加倍。

Answer 2

嗯，针对汽车行业的Genivi alliance实施并支持CommonAPI，它在DBUS之上运行，作为汽车主机的IPC机制。