什么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.

在讨论这个问题哪些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使用讨论中可以忽略

• packet/message oriented
• ability to handle both point-to-point and one-to-many communication
• no hierarchy, there's no server and client
• if one endpoint crashes, the others must be notified
• good support from existing Linux distros
• existence of a "bind" for Apache, for the purpose of creating dynamic pages -- this is too specific though, it can be ignored in a general embedded dbus usage discussion

然而另一个关于性能的问题提到了提高性能的技术。所有这一切都在照顾我，当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 ms之间的任何地方。平均6 ms。

• 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 ms。

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来打包第二个参数，则需要大约8 ms。

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.

编辑：如果您发送消息直接绕过守护进程，性能将增加一倍。

If you send messages directly bypassing the daemon, the performance would double.

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