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

Question

根据我的阅读，dbus 性能应该比其他消息传递 ipc 机制慢两倍，因为存在守护程序。

在讨论so questionwhich 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

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

Answer 2

我不认为存在任何实际和重大的性能问题。

做了一些分析：

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

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

• 1000 字节数组的第二个参数相同。如果使用定长api对第二个参数进行打包和解包，大约需要8ms。

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

总之，分析没有显示性能问题。

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

编辑：如果你send messages directly bypassing the daemon，性能会翻倍。