On Tue, Jan 3, 2012 at 8:02 PM, Marcus D. Leech
<address@hidden> wrote:
The uhd_fft.py uses the wxPython GUI interface, which does most of its work in Python. Can you separate the symbols to see more specifically where the processing is happening?
Tom
I asked for symbols when I did the opreport, but for libpython, it didn't produce a by-symbol breakdown, which seemed a bit odd. Any magic
I need to do in opreport to make that happen?
Hm, probably have to build Python in debug mode to get the symbols out, otherwise -l should do it for you with oprofile.
Wrt: wxPython--don't forget that the FFT display is *heavily* decimated in the typical case, arranging for the FFT to be called only as often
as is required the maintain the desired display rate (a few Hz, typically). But maybe that's enough?
I would guess that it's still enough. More than that, it's the only thing that Python is really doing at that point. We could create a duplicate of uhd_fft using the qtgui interface, instead (I actually have one in
https://github.com/trondeau/gr_apps called uhd_rx_qt.grc) to see what it says. Since the qt-gui is all done in C++ libraries, there should be a lot less Python in that one.
I'd do it myself, but I have too many other things to get done tonight.
Tom