0

TIBCO RV .NET API（TIBCO.Rendezvous.dll）を使用しています。

パフォーマンスの観点から、 C＃のRVチャネルからメッセージを受信して​​読み取るためのより良い方法があるかどうか知っていますか？Messageタイプ（RVメッセージの論理ラッパー）が非常に重いことがわかりました。名前またはインデックスによるフィールドの取得は、特にそれを反復/高頻度の操作と見なす場合、かなり遅くなる可能性があります。

何か案は？

4

2 に答える 2

3

C# ラッパーの主な問題は、次のことです。

  • 任意のフィールド アクセスに割り当てます (C/C++ API は、最も可能性の高いプリミティブに対して強く型付けされた高速アクセサーを公開します)
  • すべてのフィールド アクセスで参照をマークします (後でフィールドを更新する予定がなく、メモリ リークを回避したい場合を除き、これを行う必要はありません)。
  • 名前によるフィールド検索では、文字列を ac スタイルの ASCII 文字列に変換する必要があります

これらの側面は、基礎となるフィールド/名前ベースのルックアップのオーバーヘッドを小さくします。フィールドを順番に反復することにより、メッセージ内のすべてのフィールドを調べる必要があることがわかっている場合は、それ自体を回避できます。これは、C/C++ では高速です。これは、メモリを介して線形に動作し、キャッシュ フレンドリーであるためです。

個人的には、C++ API を C++ CLI で直接ラップしました (当時、.net ライブラリは標準以下の品質でした)。これを正しく行うのは複雑ですが (特に複数のアプリ ドメインがある場合)、C++ API (C API の信じられないほど薄いラッパー) とほぼ同じパフォーマンスが得られます。

プロファイリングで、メッセージ アクセス内の割り当てが原因でアプリが必要な速度で実行されていないことがわかった場合は、.net ライブラリに問題があるのではないかと思います。リフレクションを使用して、基になる IntPtr でネイティブ メッセージを取得し、MessageToolbaox (dll の内部クラス) でまったく同じ外部定義関数を使用して、ネイティブ API にドロップダウンすることができます。メッセージは、より高速なフィールド ルックアップによって相殺される場合があります。これは明らかに壊れやすく、維持するのが難しいですが、ラッパーを完全に再実装することに比べて価値があることがわかった場合は、役立つかもしれません。

于 2009-02-24T11:55:55.747 に答える
1

私は同じことを見てきました。私の経験から、C# Rv メッセージのフィールドへのアクセスは、C++ でのフィールドへのアクセスに比べて非常に遅くなります。そのため、複数のフィールドをメッセージに追加したり、メッセージから読み取ったりすることは避けたいと考えています。

1 つの解決策は、Rv 独自のメッセージ シリアル化を使用しないことです。つまり、Message.AddField() で多くのフィールドを追加したり、Message.GetField() でそれらを取得したりしないでください。代わりに、データを Opaque 型 (バイナリ バッファ、つまりバイト配列) にシリアル化できます。その後、この単一のフィールドをメッセージに追加できます。

1 つのフィールドを読み書きするだけであれば、オーバーヘッドはほとんどありません。また、独自のコードでデータを非常に高速にシリアル化および逆シリアル化できる必要があります。

于 2011-12-19T23:13:07.903 に答える