TTMSMQTTClient Performance Problems with Version V 2_0_2_0

We used version v1.3.1.1 in our software products.
This version worked well and quickly.
After updating to version 2.0.2.0 we have performance issues between Subscribe and Acknowledged.
After downgrading to v1.3.1.1 everything is ok again.
We use RadStudio 11.2 Patch 1 , FMX Delphi App (Android, Windows, MacOS, IOS,)

TTMSMQTTFileLogger Protocol with V 1.3:1:1
11.05.2023 10:22:02: DEBUG - TTMSMQTTWriterThread -- OUT - Packet: 5 Qos:1 - SENDING - attempt: 0 --- 10000010 00001011 00000000 00000101 00000000 00000110 00110101 00110110 00111001 00111000 00101111 00100011 00000000
11.05.2023 10:22:02: DEBUG - TTMSMQTTWriterThread -- OUT - Packet: 5 Qos:1 - ACKNOWLEDGED

Performance ok: 11.05.2023 10:22:02 -> 11.05.2023 10:22:02

TTMSMQTTFileLogger Protocol with V 2.0.2.0
11.05.2023 10:19:49: DEBUG - TTMSMQTTWriterThread -- Writer thread - Packet: 3 Qos:1 - SENDING - attempt: 0 --- 10000010 00001011 00000000 00000011 00000000 00000110 00110101 00110110 00111001 00111000 00101111 00100011 00000000
11.05.2023 10:19:52: DEBUG - TTMSMQTTWriterThread -- Writer thread - Packet: 3 Qos:1 - ACKNOWLEDGED

Performance not ok: 11.05.2023 10:19:49 -> 11.05.2023 10:19:52

Can you please provide a sample so we know how you use the component?
We've tried to reproduce this issue with several brokers, component configurations and operating systems without success. The FMX demos run fine on Windows 10 and Android 11.
Maybe this is due to some event handler code in your app that takes up time?

We also have performance problems with the current version. We had the problem that the TTMSMQTTClient component could not process more than approx. 50 messages per second and then first lagged behind and then terminated the connection.
I then looked at the source code of the component and found that two threads are used. In the base class TTMSMQTTWorkerThread, there is a while loop in the Execute method in which a sleep function is called. The parameter is FRunInterval. This variable is initialised in the constructor with MQTT_DEFAULT_WORKER_INTERVAL, i.e. with 10ms. I tried to reduce this value, but it had no effect. Regardless of how low the MQTT_DEFAULT_WORKER_INTERVAL was set, it remained at the magic limit of about 50 messages per second.
When I commented out the sleep statement, there was no longer any perceptible limit on the number of messages per second.
I tested it for 12 hours and could not find that omitting the call to sleep caused any problems.

Thank you for reporting this issue!

The next MQTT component version will include a new TTMSMQTTClient.CommThreadInterval property that modifies FRunInterval in the communications thread and omits the sleep call when it has a zero value.

Setting the TTMSMQTTClient.SyncedEvents property to false should also improve the performance because the events will not be synchronized but then your application will have to save the event parameter information and send a message to the main form if it wants to show that information in the user interface.

v2.0.5.0 has been released