C＃のTIBCO RVを使用してパフォーマンスを向上させる方法は？

Question

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

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

アイデアはありますか

Answer 1

c＃ラッパーの主な問題は次のとおりです。

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

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

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

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

Answer 2

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

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

1つのフィールドの読み取りと書き込みのみを行う場合、オーバーヘッドはほとんどありません。また、独自のコード内のデータを非常に高速にシリアライズおよびデシリアライズできるはずです。