从我的阅读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应该会有更少的问题或缺点。
我不认为有什么真正的大的性能问题。
做了一些剖析:
-
在arm926ejs 200MHz处理器上，方法调用和带有两个uint32参数的应答消耗0到15 ms之间的任何地方，平均为6 ms。
-
将第二个参数更改为1000字节的数组。如果使用迭代api来打包和解包第二个参数，大约需要18毫秒。
-
与1000字节数组的第二个参数相同。如果使用固定长度的api来打包和解包第二个参数，大约需要8毫秒。
-
作为比较，使用SysV msgq将消息传递给另一个进程并获得回复。它也大约是10毫秒，尽管没有优化代码并为大量示例重复测试。
总之，分析没有显示性能问题。
为了支持这个结论，在dbus页面上有一个与性能相关的页面，它只指定双上下文切换，因为使用dbus需要将消息传递给守护进程，然后再传递到目的地。
编辑:如果您直接绕过守护进程发送消息，性能将加倍。
那么，Genivi联盟，针对汽车行业，实施并支持CommonAPI，它工作在DBUS之上，作为汽车头部单元的IPC机制。