При профилировании Cython Code, что такое `stringsource`?

Question

У меня есть тяжелая функция Cython, которую я пытаюсь оптимизировать. Я профилирую в этом следующем уроке http://docs.cython.org/src/tutorial/profiling_tutorial.html. Мой выходной профиль выглядит следующим образом:

ncalls tottime percall cumtime percall filename:lineno(function) 
     1 7.521 7.521 18.945 18.945 routing_cython_core.pyx:674(resolve_flat_regions_for_drainage) 
    6189250 4.964 0.000 4.964 0.000 stringsource:323(__cinit__) 
    6189250 2.978 0.000 7.942 0.000 stringsource:618(memoryview_cwrapper) 
    6009849 0.868 0.000 0.868 0.000 routing_cython_core.pyx:630(_is_flat) 
    6189250 0.838 0.000 0.838 0.000 stringsource:345(__dealloc__) 
    6189250 0.527 0.000 0.527 0.000 stringsource:624(memoryview_check) 
    1804189 0.507 0.000 0.683 0.000 routing_cython_core.pyx:646(_is_sink) 
    15141 0.378 0.000 0.378 0.000 {_gdal_array.BandRasterIONumPy} 
     3 0.066 0.022 0.086 0.029 /home/rpsharp/local/workspace/invest-natcap.invest-3/invest_natcap/raster_utils.py:235(new_raster_from_base_uri) 
    11763 0.048 0.000 0.395 0.000 /usr/lib/python2.7/dist-packages/osgeo/gdal_array.py:189(BandReadAsArray) 

В частности я заинтересован в строках 2 и 3, которые вызывают stringsource:323(__cinit__) и stringsource:618(memoryview_cwrapper) много раз. Google включил ссылки на представления памяти, которые я не использую в этой функции, хотя я статически печатаю массивы numpy. Любая идея, что эти вызовы и если я могу избежать/оптимизировать их?

Answer 1

Хорошо, получается I есть вид памяти. Я вызывал встроенную функцию, которая передавала статически типизированный массив numpy в представление памяти, тем самым вызывая все эти дополнительные вызовы для stringsource. Замена типа памяти в вызове функции с помощью типа numpy исправил это.