10

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

在讨论使用哪种Linux IPC技术的so问题的问题时，有人提到了性能问题。除了两倍慢的因素之外，您还看到性能问题吗？您是否看到阻止 dbus 在嵌入式系统中使用的问题？

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

我应该提到另一个列出要求的问题（尽管它以 apache 为中心）：

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

另一个关于性能的问题提到了提高性能的技术。考虑到所有这些，我想在嵌入式系统中使用 dbus 时问题或缺点应该更少。

4

2 回答 2

6

我不认为有任何真正的和大的性能问题。

做了一些分析：

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

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

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

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

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

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

编辑：如果您直接绕过 daemon 发送消息，性能会翻倍。

于 2014-08-14T17:53:16.007 回答
3

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

于 2015-04-20T13:42:09.637 回答