[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Profile gr python code using Oprofile and Kcacheg
Marcus D. Leech
Re: [Discuss-gnuradio] Profile gr python code using Oprofile and Kcachegrind
Sat, 01 Sep 2012 11:43:51 -0400
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:184.108.40.206) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
To recast things in telecom/networking terms, I like to think of the
Python layer as the control plane, and the C++ layer as the
On Thu, Aug 30, 2012 at 6:17 AM, Qing Yang<address@hidden> wrote:
Kcachegrind can only show the cost of C++ functions, can we get the cost of
python functions or python modules? Because it is more interesting to look
at the cost of each gr modules in the python code level.
Information Engineering, CUHK
If you're doing performance critical stuff in Python, stop it :)
I've never worried about profiling Python code since any performance
critical stuff I've wanted to do, I do it in C++. Python is just for
interfacing and interacting with the GNU Radio flowgraph and blocks,
and that shouldn't need profiling.
There are still people out there who think that Python was a horrible
choice for Gnu Radio, because they think we're pushing significant
data through the Python layer. The hier2 blocks that are written in
Python add to this confusion, since at casual glance, it looks like
we're pushing data through Python with these, and of course, we're
not. The hier2 blocks just "encapsulate" a bunch of C++ blocks
to make a composite block, but again, Python just plays the role of
"control/constructor" plane in these scenarios.
I was on the RTLSDR chat group yesterday when I pointed out that all the
fundamental blocks in Gnu Radio are written in C++, and I got a
"well, yeah, except for all those fancy demodulator/modulator
blocks". So the misunderstanding is persistent.
Shirleys Bay Radio Astronomy Consortium