什么 dbus 性能问题会阻止它进入嵌入式系统? [英] what dbus performance issue could prevent it from embedded system?

问题描述

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

From my reading dbus performance should be twice slower than other messaging ipc mechanisms due to existence of a daemon.

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

In the discussion of the so question which Linux IPC technique to use someones mention performance issues. Do you see performance issues other than the twice slower factor? Do you see the issue that prevent dbus from being used in embedded system?

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

To my understanding if dbus is intended for small messages. If large amount of data need to be passed around, one of the solution is to put the data into shared memory or a pile, and then use dbus to notify. Other ipc mechanisms according to the so discussion being in consideration are: Signals, Anonymous Pipes, Named Pipes or FIFOs, SysV Message Queues, POSIX Message Queues, SysV Shared memory, POSIX Shared memory, SysV semaphores, POSIX semaphores, FUTEX locks, File-backed and anonymous shared memory using mmap, UNIX Domain Sockets, Netlink Sockets, Network Sockets, Inotify mechanisms, FUSE subsystem, D-Bus subsystem.

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

I should mention another so question which lists the requirements (though it is apache centered):

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

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

Yet another so question about performance mentions techniques to improve the performance. With all this being taken care of I guess there should be less issue or drawback when dbus is used in an embedded system.

推荐答案

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

I don't think there is any real-and-big performance issue.

做了一些分析:

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

• On an arm926ejs 200MHz processor, a method call and reply with two uint32 arguments consumes anywhere between 0 to 15 ms. average 6 ms.

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

Changed the 2nd parameter to an array of 1000 bytes. If use the iteration api to pack and unpack the 2nd parameter, it takes about 18 ms.

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

The same 2nd parameter of an array of 1000 bytes. If use the fixed-length api to pack and unpack the 2nd parameter, it takes about 8 ms.

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

As a comparison, use the SysV msgq passing a message to another process and getting a reply. It is about 10 ms too, though without optimizing the code and repeating the test for a large number of samples.

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

In summary, the profiling does not show a performance issue.

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

To support this conclusion, there is a performance related page on dbus page, which specifies only the double-context-switching because with dbus it needs to pass the message to the daemon then to the destination.

如果您直接绕过守护进程发送消息，性能会翻倍.

这篇关于什么 dbus 性能问题会阻止它进入嵌入式系统?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！