Improving performance
-
Presently I have an instance of QTimer that is set to 1ms, this is used to trigger processing of a large file, however its not fast enough and takes to long, each iteration of the timeout signal triggers processing of a section of the file, this continues until the entire file has been processed.
I thought I would try an improve on the time it takes to process the file by doing away with the timer and instead emitting a signal at the end of the processing, so the last line of the slot triggers the signal again, this doesn't work and I get a stack overflow.
Is there a better way to prove on the performance with a higher resolution timer or alternative?
Kind Regards,
Sy -
Presently I have an instance of QTimer that is set to 1ms, this is used to trigger processing of a large file, however its not fast enough and takes to long, each iteration of the timeout signal triggers processing of a section of the file, this continues until the entire file has been processed.
I thought I would try an improve on the time it takes to process the file by doing away with the timer and instead emitting a signal at the end of the processing, so the last line of the slot triggers the signal again, this doesn't work and I get a stack overflow.
Is there a better way to prove on the performance with a higher resolution timer or alternative?
@SPlatten said in Improving performance:
the last line of the slot triggers the signal again, this doesn't work and I get a stack overflow.
Sounds like infinite loop, leading to stack overflow.
Why do you emit SAME signal?
Why don't you simply add another signal which is emitted at the end of processing? -
@SPlatten said in Improving performance:
the last line of the slot triggers the signal again, this doesn't work and I get a stack overflow.
Sounds like infinite loop, leading to stack overflow.
Why do you emit SAME signal?
Why don't you simply add another signal which is emitted at the end of processing?@jsulm I'm really just looking for a way to trigger processing fast and efficient without locking up the GUI, I need a way to trigger processing of the file in chunks and the current implementation is just to slow. There is already another signal emitted when the processing is finished, the signal thats causing the stack overflow is a signal to continue processing.
Kind Regards,
Sy -
@jsulm I'm really just looking for a way to trigger processing fast and efficient without locking up the GUI, I need a way to trigger processing of the file in chunks and the current implementation is just to slow. There is already another signal emitted when the processing is finished, the signal thats causing the stack overflow is a signal to continue processing.
@SPlatten Do you want to process these chunks in parallel or serial?
If serial: use same signal, but add a break condition (if last chunk -> do not emit signal). -
@SPlatten Do you want to process these chunks in parallel or serial?
If serial: use same signal, but add a break condition (if last chunk -> do not emit signal).@jsulm, presently the application isn't doing much whilst the file is processed, there is a dialog displayed which shows the status and progress, so the user knows that something is being done.
I will try using a thread to solve the problem.
Kind Regards,
Sy -
@jsulm, presently the application isn't doing much whilst the file is processed, there is a dialog displayed which shows the status and progress, so the user knows that something is being done.
I will try using a thread to solve the problem.
@SPlatten Doesn't answer my question.
There is one more thing to consider: by default DirectConnection is used for signal/slot connections in same thread. That means: an emit is nothing more than a method call and if you emit same signal from the slot you basically have recursive function. If you have too many iterations you will get stack overflow. You can try to use QueuedConnection when calling connect. -
@jsulm, presently the application isn't doing much whilst the file is processed, there is a dialog displayed which shows the status and progress, so the user knows that something is being done.
I will try using a thread to solve the problem.
-
The best approach to use a QTimer is to set a timeout of 0ms. This way the timeout will be handled when the event loop is idle (not immediatly). A better way is to use a separate thread as the others already mentioned.
-
The best approach to use a QTimer is to set a timeout of 0ms. This way the timeout will be handled when the event loop is idle (not immediatly). A better way is to use a separate thread as the others already mentioned.
-
@SimonSchroeder, I've now moved to a separate thread which is so much faster than the timer could ever be on Windows.
@SPlatten said in Improving performance:
@SimonSchroeder, I've now moved to a separate thread which is so much faster than the timer could ever be on Windows.
Not using an event loop will be faster than using an event loop. Not calling a function will be faster than calling a function. Not context switching and data synchronizing will be faster than context switching and data synchronizing.
At a glance, the Windows zero timer implementation doesn't use an OS timer facility.
