Using a lot of ChangeBroadcasters


#1

Is there any significant performance drawback in using a lot of ChangeBroadcasters (like 200 or 500), each with their own ChangeListener, in an application?


#2

Compared to what? If you have to notify, then you have to notify. ChangeBroadcaster / ChangeListener is not particularly resource intensive, I doubt you could implement a faster version of it.

If performance in response to broadcasts is an issue for you then you should consider design changes that reduce the amount of broadcasting required.


#3

Thanks Vinn.

I’m getting to know JUCE by reading docs/source and trying stuff out. In this particular case I don’t expect to do a lot of broadcasting, but was pondering a design solution with a couple of hundred broadcasters/listeners. The more elegant solution would be to have separate broadcaster/listener pairs/groups, as opposed to a giant dispatcher/switch-case-thingy. I was basically wondering whether there are any strong arguments against creating that many broadcasters/listeners. Now I know there isn’t.

It’s not very specific since, so far, I’m just generally messing about in JUCE, getting ideas and questions. Thanks again.


#4

The only scaling problem you might hit would that each one will send a message, which can flood the OS’s message queue if there are many thousands of them blasting away at the same time. In that case you’d probably want to refactor a more sensible solution based on exactly what your app needs to do.


#5

If this is a problem you can use vf::Listeners, which only puts one message into the message queue no matter how many broadcasts there are.


#6

That’s also how ChangeBroadcasters work, but he’s talking about having many broadcasters, not broadcasts.


#7

Actually, that’s what I meant (broadcasters). Regardless how many vf::Listeners there are, only one message goes into the system queue (it uses a single AsyncUpdater).

This is because vf::LIsteners::addListener takes an extra parameter, the thread on which to receive notifications. For receiving notifications on the message thread you would pass MessageThread::getInstance() for all the registered listeners, thus multiplexing an unlimited number of broadcasters onto one system message.