How to get better performances using TIBCO RV from C#?

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?

Answer 1

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.