如何使用C＃中的TIBCO RV獲得更好的性能？

Question

我正在使用TIBCO RV .NET API （TIBCO.Rendezvous.dll）。

您是否知道在性能方面是否存在更好的方法來從C＃的RV通道接收和讀取消息？ 我發現Message類型-RV消息上的邏輯包裝-非常沉重。 按名稱或按索引獲取字段可能非常慢 ，尤其是當我們將其視為循環/高頻操作時。

有任何想法嗎？

Answer 1

C＃包裝器的主要問題是：

• 分配給任何字段訪問（c / C ++ API為最可能的原語公開強類型快速訪問器
• 在每個字段訪問上標記引用（除非這樣做，除非您打算隨后更新字段並希望避免內存泄漏，否則無需這樣做）
• 按名稱進行字段查找需要將字符串轉換為ac樣式的ascii字符串

這些方面將使基於基礎字段/名稱的查找的開銷相形見when，當您知道需要通過依次遍歷字段來查看消息中的每個字段時，就可以避免這些開銷。 在C / C ++中，這是快速的，因為它通過內存線性地工作，因此對緩存友好。

就個人而言，我們直接用C ++ CLI包裝了C ++ api（當時.net庫的質量不合格）。 這樣做很復雜（特別是如果您有多個應用程序域），但其性能幾乎與C ++ api相同（這是C api上非常薄的包裝器）。

如果您的剖析告訴您消息訪問權限內的分配阻止了您的應用以您需要/想要的速度運行，那么恐怕.net庫將出現問題。 您可以使用反射來獲取本機消息的基礎IntPtr，然后使用MessageToolbaox（dll中的內部類）中非常相同的外部定義函數，這些函數會下到本機api，即每次訪問一次內部字段的成本更快的字段查找可能會抵消消息。 這顯然很脆弱並且很難維護，但是如果您發現與完全重新實現其包裝程序相比值得，那可能會有所幫助。

Answer 2

我見過同樣的事情。 根據我的經驗，與使用C ++訪問它們相比，訪問C＃Rv消息中的字段非常慢。 因此，您要避免在消息中添加和讀取多個字段。

一種解決方案是不使用Rv自己的消息序列化。 也就是說，不要使用Message.AddField（）添加大量字段，也不要使用Message.GetField（）獲取它們。 相反，您可以將數據序列化為Opaque類型（這是二進制緩沖區，即字節數組）。 然后，您可以將此單個字段添加到消息中。

如果您只需要讀寫一個字段，那么開銷就很小。 而且，您應該能夠非常快速地序列化和反序列化自己代碼中的數據。