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

Question

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

你知道在性能方面是否有更好的方法來接收和閱讀來自RV通道在C＃中的消息？我發現Message類型 - RV信息的邏輯包裝 - 相當重。 通過名稱或索引來獲取字段可能會很慢，特別是當我們將其視爲經常性/高頻率操作時。

任何想法？

Answer 1

與C＃包裝的主要問題是它：

• 分配的任何字段訪問（在C/C++ API揭露強類型的快速存取的最可能的原語
• 在各個領域的標記參考訪問（你不需要做這個除非你打算隨後更新的領域，並希望避免泄漏內存）的名字
• 場需要查找的字符串轉換成交流電風格ASCII字符串

這些方面將使基於字段/名稱的查找的開銷變得更小，當您知道需要通過按順序遍歷字段來查看消息中的每個字段時，它們本身都可以避免。這在C/C++中是很快的，因爲它通過內存線性工作，因此緩存友好。我們個人使用C++ CLI直接包裝C++ api（當時.net庫的質量不合格）。這很複雜（尤其是如果你有多個應用程序域的話），但它的性能與C++ api（這是C api上的一個令人難以置信的包裝）接近。

如果您的配置文件告訴您，消息訪問內的分配阻止了您的應用程序以您需要/希望的速度運行，恐怕您將遇到.net庫問題。您可以使用反射來獲取本機消息的底層IntPtr，然後使用MessageToolbaox（dll中的一個內部類）中相同的外部定義的函數，該函數下拉到本機API，每次訪問內部字段的成本消息可能會被更快的字段查找所抵消。這顯然是脆弱的，很難維持，但如果你發現它相比完全重新實現它的包裝是值得的，它可能會有所幫助。

Answer 2

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

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

如果你只是讀寫一個字段，那麼開銷很小。你應該能夠快速地序列化和反序列化你自己代碼中的數據。