Hi @otto.to.1

The reason for using a View was to reduce the number of fields you receive in Refresh and Updates, therefore it seems quite odd that it would take longer to process messages with fewer Fields than messages with more fields.

Therefore, I would be interested in more detail so we can get a better understanding of what you are observing?

• How exactly are you measuring the latency?
• What are you doing with the decoded payload - are you performing some intensive activity like writing to a database or similar?
• What time unit are the min/max/median values above?
• How long did it take to receive the 45000 updates?
• How many times did you run each test?
• how many instruments were you subscribing?
• If the tests with and without View were at the same time of day?
• Are you connecting to a local ADS server or connecting to one of our Cloud Servers? If you are not sure please provide the hostname you connect to.
• Are you able to observe similar latency by using one of our simpler examples e.g 370__MarketPrice__Batch with minimal changes for timestamping and simply redirecting the output to a file rather than screen - i.e. not doing your current payload handling?

Also, note that running a test during a busy market activity period may not provide the same results as running at a quiet time. One example I recently came across, the user was connected to onsite servers and during certain peak activity periods their servers maximum bandwidth was breached, messages were backlogged and as a result, the application received messages which were several seconds old as the backlog slowly cleared.

Also, I cannot determine your organisation name your non-corporate email address and therefore cannot confirm if you have access to RDC - our Premium Developer support service. This is important as your particular case may require some deeper offline investigation. If you can add an additional private comment with your details that would be helpful.

Hi @otto.to.1

As you may be aware, OmmConsumerClient class provides callback interfaces to pass received messages. It is your application's responsibility to implement an application client class inheriting from OmmConsumerClient and override callback methods it desires to use for processing the Refresh, Update, StatusMsg etc.

Therefore, the amount of time taken to decode a message in your event handlers such as onUpdateMsg() will depend on your implementation within these methods as well things like the number of fields you need to decode on each invocation.

These functions are executed on the API thread, so If you want to reduce the amount of time spent within these functions - you can take various measures - e.g.:

• Use Dynamic View to reduce the number of fields you request from the server
• create additional worker threads to do some of the heavy processing - you can clone the UpdateMsg and pass it into the worker thread functions.

For more information on Dynamic views please refer to the example 360 MarketPrice_View provided with the Refintiv Realtime SDK (previously known as ElektronSDK)

It becomes worse after switching to Dynamic view. The latency for decoding is nearly doubled in this mode:

The total number of updates: 45000
median: 80
min is: 11
max is: 1396543

I use the Dynamic view in this way:

Consumer.registerClient( ReqMsg().serviceName("user").payload(ElementList().addArray(":ItemList",zArrayInterest).addArray("ENAME_VIEW_TYPE", ema_access::OmmArray().addInt(178).addInt(6).addInt(14).addInt(131).addInt(44).addInt(3900).addInt(8665).addInt(8666).addInt(8667).addInt(13432).addInt(4756).addInt(4757).addInt(12840).addInt(4345).addInt(3854).addInt(14266).addInt(5).addInt(22).addInt(25).addInt(30).addInt(31).addInt(118).addInt(3264).addInt(6614).addInt(6577).addInt(3855).addInt(14265).complete()).complete()), *this);

While without using dynamic view:

The total number of updates: 45000
median: 48
min is: 4
max is: 726

Originally I register the consumer like this:

Consumer.registerClient( ema_access::ReqMsg().serviceName("user").payload(ElementList().addArray(":ItemList",zArrayInterest).complete()), *this);