QTimer expectations

I have an PyQt5 script that reads values for sensors every three seconds. The system being monitored changes slowly so dropping a second here and there isn’t a big deal.

However I am running on a mac (just upgraded to 11.1 ) which doesn’t appear to-be very generous with the resources it gives to python. The Y axis in plot (below) is of the difference in time between samples, the X axis is table indexes not seconds. In same cases the time between QTimer timeouts is in excess of 40s. This despite the process running the PyQt5 script having almost 100% of a cpu. The longer the script runs the less responsive to user input it becomes

The GUI is just consists of 3 pygtgraphs

I experienced similar behaviour in earlier version macOS. Is this a ploy by Apple to get developers to write native applications?

Have you tried this on other platforms? I would expect inconsistent delays on most systems due to multitasking – although is your Y axis seconds? A difference from 5 - 45 seconds seems a bit odd.

Something particular about QTimer is that the events are handled through the event queue, which means they can get delayed by other parts of your program. If you have Python functions that take a 5-10 seconds to run these can block the event queue, and so prevent any subsequent timers from firing.

Threads might suffer from similar problems (becaue of the GIL), would need to see the code to know for sure. You might want to consider running this time critical code in a separate process so it’s completely isolated from the GUI, it should make quite a difference.

thanks Martin,

Yes the Y axis is time since the last timer fire.

I think in the first instance I’ll use the timer to kick-off at thread to do all or some of the tasks currently performed by the timer method, however none of them are particularly heavy weight.
Then if that bares no fruit I’ll consider moving to a separate process.