Re: [Discuss-gnuradio] Profile gr python code using Oprofile and Kcachegrind

[Marcus D. Leech]

> On Thu, Aug 30, 2012 at 6:17 AM, Qing Yang<address@hidden>  wrote:
> > Hi Tom,
> >
> > 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.
> >
> > Sincerely,
> > --
> > Yang, Qing
> > 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.
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
  data plane.

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.


--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org