Optimizing timerEvent function - static vs. member variables
-
Hi, I am trying to optimize a timerEvent function to make sure it causes as little delay as possible. The timer period is currently 10 ms. I have about 10 variables that need to persist from one timer event to another. Would it be better to use static variables in the timerEvent function, or make these class member variables? Also any other tips to speed up timerEvent. I assume I don't want to interact with the UI in there.
I am using a qPow() function. Does this take a significant amount of time? I am accustomed to the embedded world where time is very significant.
Thanks
Ron
-
If you don't interact with the UI anyway, you could simply start a separate thread with a loop and use QThread::msleep() for the delay:
@void MyThread::run(void)
{
while(!m_stop)
{
doSomething();
msleep(10);
}
}@
-
I do need to interact with the UI. I was thinking I would add a slower timer to handle the UI. Is there another way I can have something running all the time?
Ron
-
Hi,
What is this application for? This piece of information will affect the answers to your questions.
[quote author="BasicPoke" date="1398697521"]Hi, I am trying to optimize a timerEvent function to make sure it causes as little delay as possible. The timer period is currently 10 ms. I have about 10 variables that need to persist from one timer event to another. Would it be better to use static variables in the timerEvent function, or make these class member variables? Also any other tips to speed up timerEvent.[/quote]I'd expect there to be no difference between a static variable and a member variable. Generally, in object-oriented design, you'd go for member variables for code maintainability.
Note that, unlike an embedded environment, a desktop (especially Windows) is highly likely to introduce jitter in your timed loops (i.e. there's no guarantee that the timer will fire exactly every 10.0 ms).
[quote]I am using a qPow() function. Does this take a significant amount of time?[/quote]Significance is relative. The best thing to do is profile it.
[quote]I am accustomed to the embedded world where time is very significant.[/quote]The important question is: How optimized do you need to be for this application?
[quote author="BasicPoke" date="1398701639"]I was thinking I would add a slower timer to handle the UI. Is there another way I can have something running all the time?[/quote]Qt is designed as an event-driven framework, not a timed framework. We don't usually use timers to drive or poll the UI.
-
[quote author="BasicPoke" date="1398701639"]I do need to interact with the UI. I was thinking I would add a slower timer to handle the UI. Is there another way I can have something running all the time?
Ron[/quote]Having to update the UI is no reason for not using a background thread!
In your thread you can do something like:
@void MyThread::run(void)
{
while(!m_stop)
{
doThePeriodicalTask();
if(someCondition)
{
emit somethingHasHappened();
}
msleep(10);
}
}@And in your UI class:
@connect(m_thread, SIGNAL(somethingHasHappened()), this, SLOT(handleUpdate()));@ @void MyDialog::handleUpdate(void)
{
ui->my_label->setText("It has happened !!!");
}@Consequently, the periodical task will be performed every 10 milliseconds - but without interfering with the UI thread. At the same time, the UI will be updated when required. And only when required!
-
I am using the timer to poll a digital signal from a data acquisition unit. I am aware there will be jitter, but it appears to be good enough. The input signal is asynchronous serial communication and is only changing at a rate of 5 Hz.
MuldeR, what is the advantage to adding this thread, over using the timer?
Ron
-
Timer events are processed in the "main" thread (at least they'll be processed in the main thread, if you don't create a separate thread with its own event loop for that purpose). That's okay if you need to do something once in a while. But if you need to do it in 10 millisecond intervals, all the time, you are "stressing" the main thread with 100 timer events per second! And there should be absolutely no need to "poll a digital signal from a data acquisition unit" inside the GUI thread. You can send a Signal to the main thread, once the data has changed in a way that requires a GUI update.
__
Another reason: Since the GUI thread does a lot of other things, and it cannot process the timer event while it is busy with something else, it is very likely that your timer events often are delayed! By using a dedicated thread you still have no "hard" guarantees (this would require a real-time OS with "deadline" scheduling), but it should be much more reliable at least...
-
Is that RS-232? If so, have a look at "QSerialPort":http://qt-project.org/doc/qt-5/qserialport.html -- it provides a simple high-level API for asynchronous serial communications.
