[Tutor] improving speed using and recalling C functions

[Gabriele Brambilla]

Hi Danny,
I followed your suggestion.
Tomorrow morning I will run this new version of the code.

Now using a sample of 81 elements (instead of 600000) the profile returns:

Thu Apr 10 23:25:59 2014    restats

         18101188 function calls in 1218.626 seconds

   Ordered by: internal time
   List reduced from 13 to 10 due to restriction <10>

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1 1015.803 1015.803 1218.334 1218.334 skymaps5.py:44(mymain)
 18101000  202.490    0.000  202.490    0.000 {method 'write' of 'file'
objects}

        1    0.292    0.292 1218.626 1218.626 <string>:1(<module>)
        6    0.029    0.005    0.029    0.005 {open}
        5    0.010    0.002    0.010    0.002 {method 'close' of 'file'
objects}

       81    0.002    0.000    0.002    0.000 {method 'split' of 'str'
objects}
       82    0.001    0.000    0.001    0.000 {zip}
        1    0.000    0.000    0.000    0.000 function_base.py:8(linspace)
        1    0.000    0.000    0.000    0.000 function_base.py:93(logspace)
        5    0.000    0.000    0.000    0.000 {numpy.core.multiarray.zeros}


Anyway I would like to try to speed it up using C functions (and maybe
comparing the resuts of the two profile in the end)
How can I do it now? Can I use Cython?

Thanks

Gabriele



2014-04-10 21:38 GMT-04:00 Danny Yoo <dyoo at hashcollision.org>:

> > Comment:  You are looping over your sliced eel five times.  Do you
> >    need to?  I like eel salad a great deal, as well, but, how about:
> >
> >
> >        for k in eel:
> >            MYMAP1[i, j, k] = MYMAP1[i, j, k] + myinternet[oo]
> >            MYMAP2[i, j, k] = MYMAP2[i, j, k] + myinternet[oo]
> >            MYMAP3[i, j, k] = MYMAP3[i, j, k] + myinternet[oo]
> >            MYMAP4[i, j, k] = MYMAP4[i, j, k] + myinternet[oo]
> >            MYMAP5[i, j, k] = MYMAP5[i, j, k] + myinternet[oo]
> >            oo = oo + 1
>
>
> Hi Gabriele,
>
> Also note that, when Martin looked at this part of the code, he
> unfortunately misinterpreted its effect; Martin's proposed rewrite
> here does not preserve the meaning of the original code.  But rather
> than wag my finger at how Martin interpreted the code, I'd rather make
> the observation that this is a warning sign that the original code
> here was not easy to understand.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tutor/attachments/20140410/3f253850/attachment.html>