[Top][All Lists]

[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 16:08:18 -0500

On Sun, Feb 5, 2012 at 3:49 PM, Marcus D. Leech <address@hidden> wrote:
I have an application, SIDSuite, that I've been running on my hardware here for about 18 months continuously, with reasonable performance
 (the UI isn't totally-snappy, but acceptable).  Some time recently, with an upgrade of Gnu Radio, the performance became utterly
 unacceptable--the UI became unusable, and updates to the FFT and Waterfall sinks became very "chunky".  I haven't changed the
 app in months and months.

So, I started taking my Gnu Radio back further and further in time, until I was back to "normal".  I had to regress my GIT tree back to:

commit 2ed887b69a3b15840830998c4e6157176d427f60
Author: Josh Blum <address@hidden>
Date:   Sat Dec 31 13:06:01 2011 -0800

In order to get decent performance again.

I have no idea what's causing the performance melt-down, but regressing back to that commit fixes it, again with no changes to the
 application in question.

I will try creeping forward from this commit to see if I can narrow it down.  Blah.

Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

The only addition that I can think of is the max_noutputs addition that went into the scheduler, which was merge:
Made on Jan 3.

All this does is add a std::min check in line for sources and normal blocks, though, and on my machines showed absolutely no performance degradation. If this is seriously what's causing your problems, then you must have been right on the edge performance-wise and these few added cycles took you over the top.



reply via email to

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