Hi Paresy,
Recently I ran into a performance issue related to MessageSink.
I have a lighting controller that consists of the following module instances:
- Lighting Control: contains on/off state, global intensity level and some other settings of a lighting zone. Uses MessageSink to respond to a short press of a button to toggle the on/off state and responds to a long button press to increase or decrease the global intensity level.
– Luminaire: defines and controls a lighting fixture. Uses MessageSink to respond to a change of lighting state.
– Lighting Scene: defines a scene name
---- Luminaire Scene: defines on/off state, color or intensity of a luminaire in a specific scene.
This is what the object tree looks like:
A Lighting Control instance usually contains multiple luminaires. I primarily use ArtNet/DMX controlled lights but I also have some Z-Wave devices. My Z-Wave network has a few nodes with low signal quality at the edges of the mesh network. Sometimes these devices do not respond at all, in other cases it takes a few seconds for a dimmer to respond to a command.
By using independent instances to control luminaires I was hoping to create a lighting control system that would degrade gracefully in case of a communication failure. Unfortunately this is not how it works in practice.
If a lighting zone uses ArtNet/DMX lighting, the response is instant. If a lighting zone contains a Z-Wave device that is difficult to reach, the response time is several seconds. This is also the case for the DMX lights. I assume this is because MessageSink calls to multiple module instances that are registered to a specific message are executed sequentially instead of in parallel.
In my opinion this case is well suited for multi-threaded execution. Parallel execution should improve response times, avoid blocking I/O and enable more effective use of resources.
I haven’t tried IPS_RunScriptEx yet to control the Luminaire instance from the Lighting Control instance. In this case this should work well because there is a direct relation between a Lighting Control instance and underlying Luminaire instances. In other situations there is no such relation, when instances of unrelated modules act on a change of a variable. So I think it is still a good idea to enable parallel execution of MessageSink calls.