We noticed our application is Posting quite a few messages to the system queue. Although this is mostly an issue with our design we were wondering why so many AsyncUpdater messages were being sent.
I noticed that for every AsyncUpdater a message is being posted if you request an asynchronous update. So if you have a lot of AsyncUpdater’s this means a lot of messages. For instance if you use a lot of Value objects and you have asynchronous listeners to them (think Labels for instance) a lot of messages will be pumped around.
Would it be a good idea to let the AsyncUpdater’s share messages like the Timer class does? This would greatly reduce the amount of messages. Or is there a possible issue with this?
I guess it could do that, though depending on how efficient the message queue is, it may not be any faster, because essentially both ways would do the same task - i.e. take a lock, add a message to a queue (either the system queue or an internal list), then iterate that list later doing the callbacks. The system event queue is generally pretty low-overhead, as it’s crucial to the performance of all apps.
If you’re hammering it hard enough for this to be an issue then it might make more sense for you to coalesce your own events in a smarter way that’s more appropriate for what you’re doing?
We were running into the 10.000 messages limit on Windows (limit can actually be set to as low as 4000 on a Windows system through the registry) and we are researching ways to prevent our message queue building up.
Although we obviously are sending way too many messages (we have quite a complex UI) i could see how this could cause problems for others as well.
Especially because when the message queue is hit too hard messages won’t be posted anymore and the handleAsuncUpdate() callbacks won’t be made.
I don’t know if it may be helpful for you, but keep in mind that the AsyncUpdater will always post a message on the queue and handle it later.
That may not be necessary when you are calling triggerAsyncUpdate() on the message thread to begin with (for example, mainly in UI code).
In that case, you may get a significant performance benefit if you skip the post/handle message mechanism, and call handleAsyncUpdate() directly, when you detect that you are triggering the notification from the message thread.
You could embed that “skipping” logic in a generic class that inherits or uses an AsyncUpdater (I called mine “AsapUpdater”), and use it as a drop-in replacement for all the places where you used an AsyncUpdater.
