[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Serious performance regression in Gnu Radio recen
Re: [Discuss-gnuradio] Serious performance regression in Gnu Radio recent
Sun, 5 Feb 2012 17:19:39 -0500
On Sun, Feb 5, 2012 at 5:07 PM, Marcus D. Leech <address@hidden>
So performance degradation seems to scale with the size of OUTPUT_RECORD_SIZE in gr_oscope_guts.cc. This basically determines how
On 02/05/2012 04:44 PM, Marcus D. Leech wrote:
On 02/05/2012 04:08 PM, Tom Rondeau wrote:
So, what if it was your *own* commit that seemed to be causing a problem? Wouldn't that be embarrassing? I think so :-( :-(
Author: Marcus Leech <address@hidden>
Date: Sun Jan 15 23:49:52 2012 -0500
core: fix for off-by-one issue in strip chart. Increases buffer size for longer displays.
I have no idea why this should be a problem, the buffer-shifting for stripchart mode is all done on the C++ side, and the updates are
done at a fairly lazy rate (a few Hz). So it's probably an issue on the Python side with bigger plot buffers. Perhaps there's some kind of
N**2 scaling ugliness going on that wasn't immediately obvious to me when I did that patch.
I think ultimately, the plotting stuff has to move so that most of the computational stuff is done in C++ land, with only the thinnest pieces
done on the Python side.
big the messages are that are sent along to the plotter routines in Python, but the STRIPCHART routine uses it to store the strip-chart
It sounds like we need someone to work on a strip-chart functionality for the qtgui sinks. They do everything in C++ land, so we could optimize there more easily.
In other news, glad you found the problem. What do you want to do about it in the meantime, since it's your code, and I think you're the primary user of the oscope under these conditions.