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).