Momergil
23rd April 2014, 14:13
Hello!
For a moment I'm questioning the efficiency of the signals and slot mechanism available in Qt/QObject for a particular use in embedded systems where processing is limited as well as memory.
In a particular situation, a given hardware collects data from somewhere and passes it to a Qt GUI application via C implemented socket. A QThread-based class in the Qt application reads the data from the socket in a synchronous way and when the data arrives, it should process it, sending to the lots of graphs and others in widgets.
The question is: how to most efficiently do this connection between the data received and processed and the graphs?
The first option I imagined was passing by signals and slots this 1º way: a processData(QByteArray&) method in the processing thread would create the small blocks of data as they arrive and emit a signal after processed, one for each kind of data pack received. When the user, then, opens a specific graph/widget, a connect(...) is performed and the data begins to appear in the GUI. When the widget is closed, a disconnect(...) is called.
The problem of this method is that it would imply lots of calling to signals with no slots connected to them, that is, useless signal emitting, and AFAIK, the whole signal process is called by Qt even if there is not slot connected to them.
A second option I thought was that the signals emitting would be blocked by boolean flags that would be set to "true" each time a widget is open (and a connect(...) is made). This way the emitting of unconnected signals would be stopped and the problem mentioned above would cease. The problem is that in order for this system to be implemented, lots of new signals and slots would be created, one for each new flag! This would make the code far more complicated and less elegant, although there would probably be still an advantage in processing.
So I'ld like to know if there is another way of doing this which is as simpler as it can be, such as in the first way (only a connect(...) is called), but with a good improve in processing consumption as well (such as in the second solution). Of course, if someone tells me that a emit signal(...) is not executed if Qt knows that no slot is connected to it, than all doubts are ceased and I'll use the first solution.
Thanks,
Momergil
For a moment I'm questioning the efficiency of the signals and slot mechanism available in Qt/QObject for a particular use in embedded systems where processing is limited as well as memory.
In a particular situation, a given hardware collects data from somewhere and passes it to a Qt GUI application via C implemented socket. A QThread-based class in the Qt application reads the data from the socket in a synchronous way and when the data arrives, it should process it, sending to the lots of graphs and others in widgets.
The question is: how to most efficiently do this connection between the data received and processed and the graphs?
The first option I imagined was passing by signals and slots this 1º way: a processData(QByteArray&) method in the processing thread would create the small blocks of data as they arrive and emit a signal after processed, one for each kind of data pack received. When the user, then, opens a specific graph/widget, a connect(...) is performed and the data begins to appear in the GUI. When the widget is closed, a disconnect(...) is called.
The problem of this method is that it would imply lots of calling to signals with no slots connected to them, that is, useless signal emitting, and AFAIK, the whole signal process is called by Qt even if there is not slot connected to them.
A second option I thought was that the signals emitting would be blocked by boolean flags that would be set to "true" each time a widget is open (and a connect(...) is made). This way the emitting of unconnected signals would be stopped and the problem mentioned above would cease. The problem is that in order for this system to be implemented, lots of new signals and slots would be created, one for each new flag! This would make the code far more complicated and less elegant, although there would probably be still an advantage in processing.
So I'ld like to know if there is another way of doing this which is as simpler as it can be, such as in the first way (only a connect(...) is called), but with a good improve in processing consumption as well (such as in the second solution). Of course, if someone tells me that a emit signal(...) is not executed if Qt knows that no slot is connected to it, than all doubts are ceased and I'll use the first solution.
Thanks,
Momergil