[Development] performance of signal slots across threads

[Nguyen Huu Minh]

Hi,

Small update. I have isolated the signal slot communication and tested it separately and that doesn't seem to be causing the slow down on Linux.
There is still something in my code that causes the performance difference between running on Windows and on Linux, but until I can clearly isolate it I will consider this closed for now.
For those who would happen to stumble upon similar issues, I worked around it by reducing the signal and slot connections, instead having my two object call each other's functions directly.

Thank you for your help,

Minh


From: Mandeep Sandhu [mailto:mandeepsandhu.chd at gmail.com]
Sent: maandag 3 maart 2014 13:02
To: Nguyen Huu Minh
Cc: Olivier Goffart; development at qt-project.org
Subject: Re: [Development] performance of signal slots across threads


On Thu, Feb 27, 2014 at 4:47 PM, Nguyen Huu Minh <HuuMinh.Nguyen at vandewiele.com<mailto:HuuMinh.Nguyen at vandewiele.com>> wrote:
Hi,

Thank you for your reply. I will try to make a benchmark, in the meanwhile I will try to explain my situation more clearly.

My first object basically handles TCP communication to a (simulated) hardware device. There are many types of messages, but one of them is data request.
That object then emits a signal, which is connected to the other Object will serves the data.

For the TCP communication you need not have a separate thread as the QTcpServer has async APIs. Though for the 'data' object you _might_ need to do it in a different thread depending on whether the 'data acquisition' process is blocking or not.
I have used such a setup in an embedded Linux environment with a very good performance gains for our UI (we were decoding JPG images coming over the network in a separate thread, while image download was done in the main thread). You might be experiencing an implementation issue. As others have pointed out, a compilable example that shows this problem would help (and profiling too).
HTH,
-mandeep

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20140303/b016fb68/attachment.html>