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++ CLI 封装了 C++ api（当时 .net 库的质量不达标）。这很复杂（特别是如果您有多个应用程序域），但性能接近于 C++ api（它是 C api 的一个非常薄的包装器）。

如果您的分析告诉您消息访问中的分配阻止您的应用程序以您需要/想要的速度运行，我担心您的 .net 库会出现问题。您可以使用反射来获取原生消息的底层 IntPtr，然后使用 MessageToolbaox（dll 中的内部类）中相同的外部定义函数，这些函数下拉到原生 api，每次访问内部字段的成本更快的字段查找可能会抵消消息。这显然是脆弱且难以维护的，但如果您发现与完全重新实现其包装器相比它是值得的，它可能会有所帮助。

于 2009-02-24T11:55:55.747 回答
1

我也见过同样的事情。根据我的经验，与在 C++ 中访问它们相比，访问 C# Rv 消息中的字段非常慢。因此，您要避免在消息中添加和读取多个字段。

一种解决方案是不使用 Rv 自己的消息序列化。也就是说，不要用Message.AddField()添加很多字段，或者用Message.GetField()获取它们。相反，您可以将数据序列化为不透明类型（这是一个二进制缓冲区，即字节数组）。然后，您可以将此单个字段添加到消息中。

如果您所做的只是读取和写入一个字段，则开销很小。而且您应该能够非常快地序列化和反序列化您自己的代码中的数据。

于 2011-12-19T23:13:07.903 回答