Please fill out the form below before submitting, thank you!
[x] Bug exists Release Version 1.2.5 ( Master Branch)
[x] Bug exists in MQTTv3 Client on Snapshot Version 1.2.6-SNAPSHOT (Develop Branch)
[?] Bug exists in MQTTv5 Client on Snapshot Version 1.2.6-SNAPSHOT (Develop Branch)
The more subscriptions one makes with a Paho client, the more CPU power it takes to process each message, and the fewer messages can be received in a given time frame. At some point (depending on hardware) messages only trickle in slowly.
The cause for this is the way CommsCallback matches subscriptions. For each message, it loops over every single subscription to check if it matches. This quickly becomes a performance bottleneck.
For non-wildcard subscriptions, this can be improved massively by keeping those subscriptions in a separate map, and just fetching the singular matching subscription from the map. No need to iterate, since there can only ever be one direct match.
For wildcard subscriptions improving this behaviour is complex, but probably not really required, since there are not likely to be many wildcard subscriptions.
I'll make a PR implementing this.
On a side note, is there a specific reason that HashTable is used instead of, for instance, ConcurrentHashMap?
hylkevds
commented
3 years ago
Please fill out the form below before submitting, thank you!
The more subscriptions one makes with a Paho client, the more CPU power it takes to process each message, and the fewer messages can be received in a given time frame. At some point (depending on hardware) messages only trickle in slowly.
The cause for this is the way CommsCallback matches subscriptions. For each message, it loops over every single subscription to check if it matches. This quickly becomes a performance bottleneck.
For non-wildcard subscriptions, this can be improved massively by keeping those subscriptions in a separate map, and just fetching the singular matching subscription from the map. No need to iterate, since there can only ever be one direct match. For wildcard subscriptions improving this behaviour is complex, but probably not really required, since there are not likely to be many wildcard subscriptions.
I'll make a PR implementing this.
On a side note, is there a specific reason that HashTable is used instead of, for instance, ConcurrentHashMap?