Please dont run an infinite timer #600
Conversation
I was profiling the UI on Qt creator and stumbled upon this infinite timer running at 100ms interval. It took about 120us for this to be serviced on my laptop. On the printer, as suspected, this took anywhere from a few ms to few tens of ms across runs. QML Timers are synchronized with the screen render thread which updates approximately every 120ms or so, so that is technically the minimum interval that can be acheived with QML timers. More importantly the feature that this is being used for-- to show the time on the top bar, isnt really to put a high precision clock on the UI, rather to make it easier to correlate events across videos and logs provided to customer support so I think we can manage comfortably with a 1 minute error margin.
dudecc
left a comment
dudecc
left a comment
There was a problem hiding this comment.
Well so the point of this is not only to show an approximate time for lining up timestamps, but also to show whether the UI is still updating the screen, and for that we really want the blinking colon every other second instead of just the time update every minute.
While I agree this could be implemented more efficiently, this timer does not appear to have a huge impact on actual performance. With the change in this commit, on my printer while idle the CPU usage of the UI application toggles between 39% and 40% in top, and without this change, the usage is less consistent but appears to average around 41%. (My understanding is that the processing cost of the onTriggered function is pretty minimal when it does not trigger a change of the text contents, and that text change only happens once every two seconds so we don't really care if that takes ten milliseconds.)
I was profiling the UI on Qt creator and stumbled upon this infinite timer running at 100ms interval. It took about 120us for the callback to be serviced on my laptop. On the printer, as suspected, this took anywhere from a few ms to few tens of ms across runs. On the printer the callback was itself executed only every 120ms or so. so it was clearly bottle necked.
More importantly the feature that this is being used for-- to show the time on the top bar, isn't really to put a high precision clock on the UI, rather to make it easier to correlate events across videos and logs provided to customer support so I think we can manage comfortably with a 1 minute error margin.