On request of Flávio Jacinto who contacted me with additional questions on this topic and for this project.

Please be aware that SLNet subscription in their current form is a technology meant to be used for small scale scenario's to receive very fast updates of data across the dataminer setup. Where you have either very few subscriptions or short-lived ones.

Use of this in large scale scenario's has proven itself to be an easy way to overload a system in the past, especially if used from within QActions and SLScripting.

Wouter briefly touched upon it in his answer, but I want to make sure it is completely understood.  "For every generated event, that event needs to be matched against all subscriptions to know whether a client needs to receive it."

SLNet Subscriptions work fantastic on a small scale. But can very quickly have a larger impact.

The reason for this is that every 'event' that triggers, will loop through and execute EVERY single handler that was made on the SLNet connection.

For example:

Element 1, Quickaction 1: I make 20 subscriptions, for 20 parameter values.

The SLNet connection now has 20 possible triggers that will start an event.
Every event will loop and execute 20 pieces of code.

On Element 2, QuickAction 3: I decide to make 50 subscriptions, for 50 Alarm States on different elements.

The SLNet connection now has 70 possible triggers that will start an event.
Every event will loop and execute 70 pieces of code.

As you can see, every subscription made in a quickaction, doesn't just increase the number of triggers. It also effects how many pieces of code need to execute for the other events. All quickactions use the same SLNet connection, so they share everything.

Do not use this technology (SLNet Subscriptions) on a large scale as it currently exists. It's not intended for this and would require some software adjustments before it can be done.