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

Question

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

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

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

我应该提一个列出要求的问题(尽管它以apache为中心):

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

然而,关于性能的另一个问题,所以提到的技术来提高性能.考虑到这一切,我想在嵌入式系统中使用dbus时应该有更少的问题或缺点.

Answer 1

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

做了一些分析:

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

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

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

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

总之,分析不会显示性能问题.

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

编辑:如果直接绕过守护程序发送消息,性能将加倍.