Skip to content

Conversation

@ctruxaw
Copy link
Contributor

@ctruxaw ctruxaw commented May 20, 2025

When the instance is not a Controller (and hence does not use sendAllArtDMX), sendAllArtDMX runs in a tight loop without sleeps or waits. There is no need for this task to run at all for non-controllers.

ctruxaw added 2 commits May 20, 2025 00:37
When the instance is not a Controller (and hence does not use sendAllArtDMX), sendAllArtDMX runs in a tight loop without sleeps or waits. There is no need for this task to run at all for non-controllers.
Tight loop caused high CPU usage, instead simply delay until the poll period has elapsed
@ctruxaw ctruxaw changed the title FIX: If sendAllArtDMX is run for a node, it results in high CPU usage FIX: High CPU usage fixes May 20, 2025
@ctruxaw
Copy link
Contributor Author

ctruxaw commented May 20, 2025

Found another improvement:
FIX: High CPU usage waiting for SendArtPollEvent
Tight loop caused high CPU usage, instead simply delay until the poll period has elapsed

With these 2 fixes, my CPU usage went from about 40% to 10% when running as a node (I suspect the improvements, specifically for sendAllArtDMX, are less significant when running as a controller)

@patrick-dmxc
Copy link
Member

In case the of the Node-Instance its possible to send DMX if there is a Port Configured as Input.

In case of the Task.Delay(), Task.Delay is always langer as the set period, this is getting worth if the CPU is at its limits.
request a delay for exact the Time you want ends in an overshoot.

@ctruxaw
Copy link
Contributor Author

ctruxaw commented May 20, 2025

I'm only using nodes as outputs, hence this fix worked for me. I've updated the patch to instead sleep the thread in the sendAllArtDMX loop

RE: SendArtPollEvent, I'm not sure I understand the concern here. Your tight loop right now pegs the thread to 100% usage... and the timing here isn't critical, even the spec says "It is a requirement of Art-Net that all controllers broadcast an ArtPoll every 2.5 to 3 seconds." - so perhaps change the 2.7 to 2.5, but the timing here should be close enough to be within spec.

These two fixes should cause your code to use about 1/3 the CPU load it did before

@patrick-dmxc patrick-dmxc merged commit 8cc6acd into DMXControl:main May 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants