# Duration of Calculations in Python scripts **URL:** \ **Category:** GNU Radio\ **Created:** [February 23, 2012, 10:40am UTC](https://www.ruby-forum.com/t/duration-of-calculations-in-python-scripts/217177 "2012-02-23T10:40:02Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![dubstep](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/cdc98d/32.png) [@dubstep](https://www.ruby-forum.com/u/dubstep)\ **Post date:** [February 23, 2012, 10:40am UTC](https://www.ruby-forum.com/t/duration-of-calculations-in-python-scripts/217177/1 "2012-02-23T10:40:02Z")
Hello, in the context of spectrum sensing in the 2.4 GHz band using a modified version of the usrp\_spectrum\_sense.py script, I am having problems with high latency times. Since the time for recording samples and all the tuning stuff is supposed to be much less than what I am currently dealing with (something around 88ms between two center frequencies), I was wondering if this might be a problem of some additional calculations the python script is doing with every message I get from the c++ code. In particular these calculations contain summing up the vector I get from the queue of the source and comparing the sum to a previously calculated threshold wrapped into some if-statements Any statements highly appreciated. Thanks. -Sebastian ---
**Author:** ![SSSebastian\_DSSring](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@SSSebastian\_DSSring](https://www.ruby-forum.com/u/SSSebastian_DSSring)\ **Post date:** [February 23, 2012, 4:30pm UTC](https://www.ruby-forum.com/t/duration-of-calculations-in-python-scripts/217177/2 "2012-02-23T16:30:24Z")
On Thu, Feb 23, 2012 at 4:39 AM, Sebastian D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)wrote: > In particular these calculations contain summing up the vector I get from > the queue of the source and comparing the sum to a previously calculated > threshold wrapped into some if-statements > > Any statements highly appreciated. > > Thanks. > -Sebastian If it’s latency in the flowgraph, you can try and use the new max\_noutput\_items (pass this value to tb.start(N) or tb.run(N), whichever is being used). The smaller this number, the faster blocks will pass data between eachother, but also the harder your computer is going to have to work to keep up. If you think that the latency is due to Python calculations, you can think about finding a more efficient scipy implementation of the calculations. If one doesn’t exist, you can write some C code and look at the f2py program that comes with Python; it’s a simpler wrapper generator than SWIG that converts from FORTAN to Python, but I believe it nicely supports C functions as well. Just a couple of thoughts. Tom ---
**Author:** ![SSSebastian\_DSSring](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@SSSebastian\_DSSring](https://www.ruby-forum.com/u/SSSebastian_DSSring)\ **Post date:** [February 24, 2012, 12:59pm UTC](https://www.ruby-forum.com/t/duration-of-calculations-in-python-scripts/217177/3 "2012-02-24T12:59:23Z")
On Thu, 23 Feb 2012 10:29:02 -0500 Tom R. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > Since the time for recording samples and all the tuning > > the queue of the source and comparing the sum to a > > If it’s latency in the flowgraph, you can try and use > > calculations, you can think > > Just a couple of thoughts. > > Tom Thanks Tom, I have proofed your suggestions, but none of them seemed to help much. I also ran the script under cProfile to get a better timing analysis and it turns out that “gr\_py\_msg\_queue\_\_delete\_head” is the real evildoer. According to cProfile it takes 94ms per call. Since cProfile produces some overhead itself, this is pretty much what fits into these almost 90ms I measured myself. Does anyone have an idea if and how this could be speeded up? Thanks -Sebastian