[Numpy-discussion] Evaluating performance of f2py extensions with gprof, why spending time _gfortran_compare_string

Åsmund Hjulstad asmund.hjulstad@gmail....
Tue Aug 24 06:16:09 CDT 2010

2010/8/18 Åsmund Hjulstad <asmund.hjulstad@gmail.com>

> I am calling a few functions in a fortran library. All parameters are short
> (longest array of 20 elements), and I do three calls to the fortran library
> pr iteration. According to the python profiler (running the script as %run
> -p in ipython), all time is spent in the python extension.
> I built the extension with options  -pg -O , ran a test script, and
> evaluated the output with
> gprof <libraryname>.py -b
> with the following output:
> Flat profile:
> Each sample counts as 0.01 seconds.
>   %   cumulative   self              self     total
>  time   seconds   seconds    calls  Ts/call  Ts/call  name
>  41.64      5.03     5.03
> _gfortran_compare_string
>  27.40      8.34     3.31                             rdxhmx_

I have found one gotcha in my approach, and that is that I have been
building the extension using distutils. It appears that extra_compile_args
options are not passed to fortran compilers (only c compilers). As a result,
the call graph was missing most of the interesting information. After a
change in GnuFCompiler, I now force distutils to compile fortran codes with
-pg enabled.

Perhaps this should be filed as a feature request?  (distutils compilation
with profiling enabled?, or at least the option of passing additional
arguments to gfortran)

Back to my original problem, though, I'm still struggling. What is calling
_gfortran_compare_string, that still is taking up more than 40% of
processing time?

[6]     43.1    5.10    0.00                 _gfortran_compare_string [6]

Any suggestions?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20100824/b1855503/attachment-0001.html 

More information about the NumPy-Discussion mailing list