You are not logged in.

Dear visitor, welcome to QtForum.org. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

1

Saturday, May 21st 2011, 6:07pm

slow computations in new thread

Hello,

I have observed an increase in execution time for code running in a thread compared to the one run in the main gui thread (4,5 x increase):
- given that a new thread is started from the gui by click of a button
- the thread contains computational intensive calculations
- the thread updates a progress bar in gui by means of signals/slots in 10% steps.

Is the use of qthreads or the presence of an eventloop inside the thread slowing down the calculations, as a general rule, or I am getting something done wrong ?

Any thoughts appreciated :)
Thx,
bion

raviteja

Beginner

  • "raviteja" is male

Posts: 6

Location: Banglore, India

  • Send private message

2

Tuesday, May 24th 2011, 7:01am

Hi,

Even i have faced same problem with signal/slot in thread. Now i used timers instead of thread concept.




withRegards,
raviteja [TTGUY]

3

Tuesday, May 24th 2011, 9:16am

The default behaviour for signals emitted from a different thread than the receiver one is that they are queued, and the slot is executed in the event loop of the receiver, when it's scheduled again.
This means that no cpu must be used by the thread to update the gui. Did you check if the increase of execution time is related to the gui update?
What happens disconnecting the progress bar, or skipping the 'emit' from the calc thread?
I don't want to focus only on signals, but another simple but sometimes useful trick is to avoid emitting the signal if the progress isn't changed. The 10% you are talking about is calculated by the thread that emits the signal? In this case, for all the job, you have only 100 / 10 + 1 = 11 signals emitted: this should not decrease performance.

4

Tuesday, June 7th 2011, 9:40pm

I was emitting the update signal once for each 10% only and the gui update was light. Unfortunately, the design has been changed I will not be able to test to find the cause of the problem

Thank you both for the answers and suggestions.