You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In short, consider this:
fieldList.clear().addReal(123);
FieldList::clear ends up calling Encoder::releaseEncIterator, which requires locking. This is immediately followed by Encoder::acquireEncIterator when encoding new data on cleared FieldList, again requiring locking. This whole release/acquire cycle doesn't seem to do anything except clearing EncIterator on acquisition.
@maciek-gc Thank you for reporting this observation! We've created an internal Jira to look into this issue and decide whether anything can be done about it.
Full context here: https://community.developers.refinitiv.com/questions/100431/emac-fieldlistupdatemsg-performance-with-multithre.html?childToView=100441#answer-100441
In short, consider this:
fieldList.clear().addReal(123);
FieldList::clear ends up calling Encoder::releaseEncIterator, which requires locking. This is immediately followed by Encoder::acquireEncIterator when encoding new data on cleared FieldList, again requiring locking. This whole release/acquire cycle doesn't seem to do anything except clearing EncIterator on acquisition.
I think the call to Encoder::releaseEncIterator could be replaced with Encoder::clear (https://github.com/Refinitiv/Real-Time-SDK/blob/master/Cpp-C/Ema/Src/Access/Impl/FieldListEncoder.cpp#L51)
Similar scenario applies to UpdateMsg (and possibly other messages, it's just Update is gross majority of what I'm generating).
The text was updated successfully, but these errors were encountered: