Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
More single signals vs one signal with data
guerinoni last edited by
Hi, something I ask me if it is better to emit five or ten or many signals when every property is modified or maybe is better emit only one signal with a vector of property as an argument. Which solution is more expensive in terms of performance and code flexibility?
Pablo J. Rogina last edited by Pablo J. Rogina
@guerinoni what will you do when only one of the ten properties is updated, and you have only one signal with a vector?
are you going to emit that signal with the vector having the old nine values plus the new value?
How will somebody connected to such signal know about what property did indeed change?
rrlopez last edited by
Hello @guerinoni ,
I would not recommend doing a vector of signals for several reasons.
Lets say you are going to emit the following signal:
vector = [a, b, c] emit signalVector[vector]
Every slot you would want to connect to this signal would then have to receive the vector argument. This in my opinion has several drawbacks:
- What if one of your slots will be using only the b value, ignoring a and c? Then you have two unused values everytime the signal is triggered.
- Is every property going to change when you emit this signal? If not, you are sending duplicate data to your listeners, which is never a good thing.
- How are you going to access each property of the vector? By index? If so, your code is not very flexible because you would then need to have a strict structure on how to add these properties to the vector.
Number 3 could be solved by not using a vector, but multiple parameters:
signalVector(int a, int b, int c, ...)
However, this appoach has its drawbacks as well (adding up number 1 and number 2 from the previous approach as well):
- Each time you would want to add a new property to the vector, you will have to modify all slots and connections to this signal, which is not a good design.
NOTE: if every property you plan on clustering up is related (i.e. you need all 3 to determine a state change or anything else), then I think this second approach is better, because all of the variables are going to be used every time to determine what needs to be done and your signal and slots will not grow for every other unrelated property.
Using individual signals for each property will indeed generate more calls for slots, however, I believe the performance decay will not be as much as you think it could be.
It is up to you to evaluate if the drawbacks presented for the previous implementations would not be an issue for you.
I hope this clarifies your mind about this issue.
if every property you plan on clustering up is related (i.e. you need all 3 to determine a state change or anything else), then I think this second approach is better, because all of the variables are going to be used every time to determine what needs to be done and your signal and slots will not grow for every other unrelated property.
That almost certainly warrants a dedicated struct spanning these properties, though. So you emit one instance of said struct and modify it as a whole.
Kent-Dorfman last edited by
The answer is [drum roll please]...it depends on your use case. sending a single signal is more efficient than sending several, but if in fact each entity is signal worthy then they should be discrete signals. A common way of IPC in my world is a shared memory region that is mutex guarded. Any task can read atomic values from that region but only the holder of the mutex can update any entries. It all boils down to use case justification.
guerinoni last edited by
@Pablo-J-Rogina @rrlopez @kshegunov @Kent-Dorfman
Many thanks for your explanation, maybe in my this case I can emit all 3
structas a single signal with a vector of parameters, but my question was for any possible case when I have to choose between
emit100 signal or one signal with 100 parameters. I'll keep in mind these considerations.