Question

I'm using TIBCO RV .NET API (TIBCO.Rendezvous.dll).

Do you know if there is a better way, in term of performance, to receive and read messages from a RV channel in C#? I found the Message type - the logical wrapper over a RV message - being quite heavy. Getting a field by name or by index could be pretty slow, especially when we consider that as a recurrent/high frequency operation.

Any ideas?

Was it helpful?

Solution

The main issue with the c# wrapper is that it:

  • Allocates for any field access (the c/C++ api expose strongly typed fast accessors for the most likely primitives
  • marks references on every field access (you don't need to do this unless you plan on subsequently updating the fields and wish to avoid leaking memory)
  • field lookups by name require conversion of the string into a c style ascii string

Those aspects will dwarf the overhead of the underlying field/name based lookups, which themselves can be avoided when you know you need to look at every field in the message by iterating through the fields in order. This is fast in C/C++ since it works linearly through memory and is thus cache friendly.

Personally we wrapped the C++ api directly with C++ CLI (at the time the .net library was of substandard quality). This is complex to get right (especially if you have multiple app domains) but gives close to the same performance as the C++ api (which is an incredibly thin wrapper on the C api).

If your profiling tells you that the allocations within the message access are preventing your app running at the speed you need/want I'm afraid you will have a problem with the .net library. You can use reflection to get at the underlying IntPtr to the native message and then use the very same externally defined functions in MessageToolbaox (an internal class in the dll) which drop down to the native api, the cost of accessing the internal field once per message may be offset by the faster field lookup. This is obviously fragile and hard to maintain but if you find that it's worth it compared to reimplementing their wrapper in full it might help.

OTHER TIPS

I have seen the same thing. From my experience, accessing fields in C# Rv messages is very slow compared with accessing them in C++. So you want to avoid adding and reading multiple fields to and from the message.

One solution is to not use Rv's own message serialization. That is, don't add lots of fields with Message.AddField(), or get them with Message.GetField(). Instead, you can serialize your data to an Opaque type (which is a binary buffer, ie a byte array). You can then add this single field to the message.

If all you do is read and write one field, there is very little overhead. And you should be able to serialize and deserialize the data in your own code pretty fast.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top