On Friday 10 October 2008 01:15:56 Johnathan Corgan wrote:
>
> I have used PMT/mblock in some commercial contract work.  I agree that
> there are performance improvements to be made in a number of places,
> but the "late binding" nature of the dynamic typing is sort of what
> PMT is all about, and makes possible the simplicity of the mblock
> design.

I found at least one point which gives some improvement - there are a few 
functions, which take an argument of type "pmt_t", but can be changed 
to "const pmt_t&" without any negative side effect.

(Passing pmt_t by value creates an pmt_t instance, using a reference does not. 
For e.g. pmt_eq, this saves creation of two pmt_t instances, including cost 
for malloc'ing and so on.)

Functions which should be changed are for example pmt_eq (and similar), 
pmt_to_long (and similar). This breaks ABI, but not API, but the gain is 
quite substantial - this saves ~30 instructions _per sample_ for the 
test_usrp_inband_rx example.


At the moment, I am experimenting with memory pools for some of the passed 
objects - this should give some improvement (most time is spent in 
malloc/free), without breaking ref counting, polymorphic types ...
Malloc/Free is taking most of the time atm, so lets see what this brings.

Stefan

PS: If you are wondering what I am using for analysis, its valgrind's 
callgrind tool, and kcachegrind for visualization. 

-- 
Stefan Brüns  /  Bergstraße 21  /  52062 Aachen
mailto:lurch at gmx.li  http://www.kawo1.rwth-aachen.de/~lurchi/
   phone: +49 241 53809034     mobile: +49 151 50412019


_______________________________________________
Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to