Re: [Discuss-gnuradio] Serious performance regression in Gnu Radio recent

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 :-( :-(
>
> commit 2a2411a598c222e2ef82b857c0b53e0a9d1daf3f
> Author: Marcus Leech <mleech@ripnet.com>
> 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.
>
>
>
>
So performance degradation seems to scale with the size of
OUTPUT_RECORD_SIZE in gr_oscope_guts.cc. This basically determines how
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
samples in.

--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio