2010/8/18 Åsmund Hjulstad <[email protected]>
>
> 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?
-----------------------------------------------
<spontaneous>
[6] 43.1 5.10 0.00 _gfortran_compare_string [6]
-----------------------------------------------
Any suggestions?
_______________________________________________
NumPy-Discussion mailing list
[email protected]
http://mail.scipy.org/mailman/listinfo/numpy-discussion
