Performance of signals/slots for plotting/oscilloscope (performance questions)
-
Also, in the the receiving slot I tried to create a smart pointer with make_unique. For some reason adding that caused my app to crash. It was very odd. The pointer was valid so I don't understand what happened. By the time it hits the slot it should be running in the GUI (main) thread.
-
@fcarney said in Performance of signals/slots for plotting/oscilloscope (performance questions):
If a slot is called multiple times is this queued up
the the emitting signal is from a different thread , than yes, they are queued up and called one after the other
Is there a better way to isolate the QThread from the main thread different from signals to get better performance
There's QMutex it's more low level but can be a good amount faster than Signal/Slot
Is there a better way to approach writing an oscilloscope type system?
No Ideas sorry 😔
-
-
Here is my solution to reading data in and buffering:
CircularBufferI have some planned expansion of this buffer, but so far it performs really well. I read up more on signals. It does have some overhead, but so far it has been acceptable performance. I did find an article that explained the overhead for differing kinds of signal/slot operations. They are not great, but they are not bad either.
-
Some food for thought:
Your buffer doesn't have smash-protection (just noting) and more importantly it is not thread safe. Is this by design?
When thinking about a circular buffer you have to be careful how you distinguish full one and an empty one (i.e. when the begin iterator gets equal to the end iterator). -
@kshegunov said in Performance of signals/slots for plotting/oscilloscope (performance questions):
Your buffer doesn't have smash-protection (just noting) and more importantly it is not thread safe.
Not sure what smash-protection is.
I need to learn more about making code thread safe. I am currently using it in a single thread. That may change though. Is it because operations are not atomic?I expect the fake iterators to be used in a way that allows comparisons for equality to prevent going beyond the end of the buffer. I need to add an operator== to the sub class.
Edit:
I just went ahead and got a modern book on C++ multithreading. I need to get a better feel for thread safety. -
@fcarney said in Performance of signals/slots for plotting/oscilloscope (performance questions):
Not sure what smash-protection is.
You don't have a guard in place to prevent you (or at least signal you) if you overfill the buffer. Say you take 250 item buffer, if you insert 251 items, then your code is going to wrongly assume that it has 1 item.
Is it because operations are not atomic?
Yes, but even if they were atomic that doesn't solve all problems. Actually, lockless programming is rather more complicated than writing blocking code.
I expect the fake iterators to be used in a way that allows comparisons for equality to prevent going beyond the end of the buffer.
That's correct thinking. They should wrap around internally.
I need to add an operator== to the sub class.
And some other bells and whistles. For example there's no distinction between an empty and full buffer; just between an empty and a partially filled one.
You could've just used the
std::vectoriterator as a typedef, since you@fcarney said in Performance of signals/slots for plotting/oscilloscope (performance questions):
I just went ahead and got a modern book on C++ multithreading. I need to get a better feel for thread safety.
It boils down to one principle - not to allow simultaneous mutation on a data field. In practice, however, realizing this requirement isn't so trivial. One note, C++ multithreading has nothing to do with C++ specifically; it's the same in pretty much every language there is.
-
@kshegunov said in Performance of signals/slots for plotting/oscilloscope (performance questions):
You don't have a guard in place
When you push a value into the buffer and m_end meets up m_begin, then m_begin gets pushed ahead. So at that point it is lossy. For my use case I use up the data faster than I put in the data. But yes, if the input rate exceeds the output rate it will move the m_begin forward as a result. This is so it favors more recent data in case it stops consuming for some reason.
You could've just used the std::vector iterator as a typedef, since you
? not sure what you mean here.
-
@fcarney said in Performance of signals/slots for plotting/oscilloscope (performance questions):
So at that point it is lossy.
Yes, that's my point.
This is so it favors more recent data in case it stops consuming for some reason.
Yes, but you don't shift the old elements back so you're always dropping the oldest. You invalidate all of them and start anew.
? not sure what you mean here.
Something I was thinking, and thinking about it badly. Just disregard it it's just a remnant from a thought process (unfinished and worng).
-
@kshegunov said in Performance of signals/slots for plotting/oscilloscope (performance questions):
Yes, but you don't shift the old elements back so you're always dropping the oldest. You invalidate all of them and start anew.
I guess I don't understand what you mean. I want it to lose the old data. It shifts the m_begin forward. So it stays the same size once it is full. Right at 512 elements. I have tested this. m_end does not pass up m_begin.
Oh, and the external begin and end pseudo iterators need more work anyway. The push and pop are primarily what I use for adding and removing data.
-
@kshegunov said in Performance of signals/slots for plotting/oscilloscope (performance questions):
invalidate all of them
I think I see what you mean here (brain finally comprehending...). I need some bounds on my iterator manipulation. Thanks for pointing this out.
