Decided this evening to grab some quick profile data for a uhd_fft.py,
running at 50Msps from a USRP2.
The kernel was occupied 41% of the time–no great surprise. Handling
interrupts, doing the network stack “stuff”.
The next largest chunk was libc (memcpy_sse) 12.5%
Then uhd (convert_sc8_item32_1_to_fcxx_1) 11.4%
Then libpython
9.8%
Then libgnuradio-core 7.5%
So, the big surprise there was that libpython was so high on the list,
since Python isn’t used in copying data within the flow-graph. I didn’t
get any symbol information for libpython, so I wonder what it is
doing all that time?
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
On Tue, Jan 3, 2012 at 7:41 PM, Marcus D. Leech [email protected]
wrote:
Then libgnuradio-core 7.5%
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
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
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?
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?
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
On Tue, Jan 3, 2012 at 17:02, Marcus D. Leech [email protected] wrote:
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?
The wxPython FFT sink works by creating a FFT vectors, passing them (via
a
GR message queue) to a non-GR Python thread, which does some
processing/preparation and posts events to the wxPython window system
for
plotting.
It would be useful to rewrite this as a straight C++ GNU Radio app using
the QT widgets.
Johnathan
On Tue, Jan 3, 2012 at 8:02 PM, Marcus D. Leech [email protected]
wrote:
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
GitHub - trondeau/gr_apps: GNU Radio applications 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
–