discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] Serious performance regression in Gnu Radio recent
Date: Sun, 5 Feb 2012 17:19:39 -0500

On Sun, Feb 5, 2012 at 5:07 PM, Marcus D. Leech <address@hidden> wrote:
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 <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.




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


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.

Tom


reply via email to

[Prev in Thread] Current Thread [Next in Thread]