Using a lot of ChangeBroadcasters

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

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.

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.

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.

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.

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

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.