Windows プラットフォームで、送信側と受信側の両方が C++ で記述されている超高速 MQ メカニズムが必要です。
IPC にRCF-C++を使用した現在の実装では、Windows 名前付きパイプを介して約 20,000 メッセージ/秒でクロックを処理しています。
私はデモアプリに従ってboost::interprocess Message Queuesのパフォーマンスをテストしており、約48,000メッセージ/秒を測定していますが、これは驚くほど遅いです。このブログ投稿のコードを使用した C# )、約 150,000 メッセージ/秒を取得しました。
ブースト message_queue のパフォーマンスが非常に遅い理由と、それを改善するために何ができるかについてのアイデアはありますか?
ダニエルの答えはその一部ですが、ここにはより大きな問題があります: boost::interprocess は基本的にキューを共有メモリ内の配列として維持し、メッセージを送信すると、boost::interprocess:message_queue はに基づいてバイナリ検索を行います新しいメッセージの優先度を使用して、メッセージを配列内のどこに配置する必要があるかを調べstd::backward_copy、他のすべてのメッセージを s してそのための場所を空けます。常に同じ優先度を使用すると、メッセージは (最新であるため) 最初に配置されるため、その時点でバッファーにあるメッセージはすべて backwards_copied されて、そのためのスペースが確保されますが、これには時間がかかります。(queue_free_msgメソッドの実装を参照してください)。
メッセージに優先順位を付ける必要がなく、通常の FIFO キューが必要な場合、このアプローチはCircular Bufferを使用するよりもはるかに遅くなります。キューのサイズが大きくなると、挿入 (送信) のパフォーマンスが急速に低下します。
更新:ウィキペディアのメモの助けを借りて、内部で循環バッファーを使用する message_queue のバージョンを作成しましたが、これは大成功でした。
Boost のドキュメントに記載されているように、boost::interprocess::shared_memory_object は Win32 のメモリ マップ ファイルを使用して実装されています。また、boost のメッセージ キューも、そのシミュレートされた共有メモリ オブジェクトを使用しています。(ネイティブの Win32 共有メモリの場合、boost は windows_shared_memory クラスを別途提供します。)
したがって、メッセージ キューのパフォーマンスを向上させるには、ネイティブの Win32 共有メモリ オブジェクトを使用して独自のバージョンのメッセージ キューを実装する必要があります。私の実験では、交換後、パフォーマンスが著しく向上しました。
Win32 ネイティブ共有メモリに変更する場合は、共有メモリの「削除」に注意する必要があります。POSIX 共有メモリと Win32 共有メモリでは、削除のポリシーが異なります。