10

私の読書によると、デーモンの存在により、dbus のパフォーマンスは他のメッセージング ipc メカニズムよりも 2 倍遅くなるはずです。

どのLinux IPC手法を使用するかという質問の議論で、誰かがパフォーマンスの問題について言及しています。2 倍の速度低下以外のパフォーマンスの問題はありますか? 組み込みシステムで dbus を使用できないという問題はありますか?

dbus が小さなメッセージを対象としているかどうかは、私の理解に基づいています。大量のデータを渡す必要がある場合、解決策の 1 つは、データを共有メモリまたはパイルに配置し、dbus を使用して通知することです。検討中の議論によるその他の ipc メカニズムは次のとおりです。シグナル、匿名パイプ、名前付きパイプまたは FIFO、SysV メッセージ キュー、POSIX メッセージ キュー、SysV 共有メモリ、POSIX 共有メモリ、SysV セマフォ、POSIX セマフォ、FUTEX ロックmmap、UNIX ドメイン ソケット、Netlink ソケット、ネットワーク ソケット、Inotify メカニズム、FUSE サブシステム、D-Bus サブシステムを使用した、バックアップされた匿名共有メモリ。

要件をリストする別の質問に言及する必要があります（ただし、Apache中心です）：

  • パケット/メッセージ指向
  • ポイントツーポイントと 1 対多の通信の両方を処理する機能
  • 階層なし、サーバーとクライアントなし
  • 1 つのエンドポイントがクラッシュした場合、他のエンドポイントに通知する必要があります
  • 既存の Linux ディストリビューションからの優れたサポート
  • 動的ページを作成するための Apache 用の「バインド」の存在 -- これはあまりにも具体的ですが、一般的な埋め込み dbus の使用に関する議論では無視できます。

パフォーマンスに関するさらに別の質問では、パフォーマンスを向上させるためのテクニックについて言及しています。これらすべてに対処することで、組み込みシステムで dbus を使用する場合の問題や欠点が少なくなるはずです。

4

2 に答える 2

6

実際の大きなパフォーマンスの問題はないと思います。

いくつかのプロファイリングを行いました:

  • arm926ejs 200MHz プロセッサでは、2 つの uint32 引数を使用したメソッドの呼び出しと応答は、0 ～ 15 ミリ秒の間で消費します。平均 6 ミリ秒。

  • 2 番目のパラメーターを 1000 バイトの配列に変更しました。反復 API を使用して 2 番目のパラメーターをパックおよびアンパックすると、約 18 ミリ秒かかります。

  • 1000 バイトの配列の同じ 2 番目のパラメーター。固定長 API を使用して 2 番目のパラメーターをパックおよびアンパックすると、約 8 ミリ秒かかります。

  • 比較として、メッセージを別のプロセスに渡し、応答を取得する SysV msgq を使用します。コードを最適化したり、多数のサンプルに対してテストを繰り返したりしなくても、これも約 10 ミリ秒です。

要約すると、プロファイリングはパフォーマンスの問題を示しません。

この結論を支持するために、dbus ページにパフォーマンス関連のページがあります。これは、dbus ではメッセージをデーモンに渡してから宛先に渡す必要があるため、ダブル コンテキスト スイッチングのみを指定します。

編集：デーモンをバイパスしてメッセージを直接送信すると、パフォーマンスが2倍になります。

于 2014-08-14T17:53:16.007 に答える
3

自動車産業を対象とするGenivi アライアンスは、自動車のヘッド ユニットの IPC メカニズムとして、DBUS 上で動作 するCommonAPIを実装およびサポートしています。

于 2015-04-20T13:42:09.637 に答える