Performance of signals/slots for plotting/oscilloscope (performance questions)
-
-
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.
C++ is a perfectly valid school of magic.
-
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.C++ is a perfectly valid school of magic.
-
@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.
C++ is a perfectly valid school of magic.
-
@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.
C++ is a perfectly valid school of magic.
-
@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.
Yeah, sorry for not writing, I was rather busy. This indeed was my point.
