¿Compilación de scripts Python (a .exe) que utilizan las herramientas de geoprocesamiento de ArcGIS?

Question

Llevo varios meses codificando con Python y he desarrollado algunos scripts razonablemente complejos para tareas principalmente de geoprocesamiento. Dicho esto, todavía estoy aprendiendo mucho, ya que vengo de un fondo SQL / VBA / VBScript.

Sé que el código compilado normalmente se ejecuta más rápido que el código que debe ser procesado por un intérprete del lenguaje, así que estoy interesado en la posibilidad de compilar un script Python de geoprocesamiento a un archivo .EXE para trabajar con big data.

¿Es esto posible? Si lo es, ¿cuál es la mejor manera de compilar un script Python (.py) que está importando los módulos arcgisscripting o arcpy?

He pasado unos minutos intentando encontrar lo que quiero hacer y la búsqueda me ha devuelto este artículo entre otros: http://www.ehow.com/how_2091641_compile-python-code.html

El compilador parecía funcionar, pero al ejecutar el archivo .EXE resultante, daba un críptico error diciendo que algunos archivos no estaban disponibles.

El script de Python se ejecuta lo que parece ser razonablemente bien desde la línea de comandos, pero me pregunto si podría ver alguna ligera mejora si yo fuera capaz de compilar el archivo .py. Una vez más, estoy trabajando con algunos grandes conjuntos de datos que están tomando + 20 horas para procesar (delineación de las cuencas hidrográficas de los sitios de entrada de muestras de calidad del agua). Tomaré cualquier cosa que pueda conseguir en forma de mejoras.

El script se ejecutó un 10% más rápido fuera de ArcGIS desde la línea de comandos utilizando un conjunto de sitios de prueba frente a configurar el script como una herramienta de script en una nueva caja de herramientas en ArcCatalog. He estado ejecutando el script desde la línea de comandos w/o cualquier instancia de ArcGIS abierto en una máquina dedicada.

Entonces, ¿es posible compilar scripts en Python que importen el módulo arcgisscripting y que llamen a las herramientas de ArcToolBox?

EDITAR

Gracias por la aportación, me resulta muy útil. La secuencia de comandos es en gran medida una manera de coordinar una serie de herramientas de ArcGIS y la salida en los formatos deseados / lugares / con la atribución apropiada. Ya he recortado un poco de grasa creo que al escribir en una carpeta de cero en lugar de una geodatabase personal de cero para algunos archivos raster provisionales para que puedan ser almacenados en el formato ESRI GRID frente al formato IMG. Voy a comprobar las sugerencias perfilador sin embargo.

Hay algunos en mi oficina que cuestionan a Python diciendo "que el código compilado es mucho más rápido que el código que se ejecuta a través de un intérprete" principalmente en comparación con, digamos, un programa compilado de Visual Basic o VB.NET, pero es un buen punto que las herramientas van a tomar tiempo de cualquier manera. Y, parece que con las máquinas de computación de hoy en día que el código interpretado puede no ser mucho más lento que el código compilado para justificar ir esa milla extra.

EDITAR - actualización sobre la optimización del programa con formatos raster.

Quería hacer un seguimiento de mi "optimización" de este programa Python, y yo era capaz de afeitarse 2 horas de tiempo de procesamiento escribiendo rásters provisionales a formato GRID en lugar de a una geodatabase personal. No sólo eso, hubo una reducción SIGNIFICATIVA en el consumo de espacio en disco de tamaño de datos. La ejecución original que hice escribiendo todos los rásters (y eran sólo características de punto convertidas a rásters, y luego rásters de cuencas hidrográficas) resultó en 37,1 GB de datos sólo para esos archivos. Escribiendo las dos últimas salidas de datos a una carpeta en formato GRID se redujo a 667 MB de datos.

Tendría curiosidad por ver cómo un archivo GDB manejaría estos datos, aunque principalmente en la forma del tamaño de los datos. Sin embargo, reducir mi tiempo de procesamiento de 9,5 horas a 7,5 horas es suficiente para abogar por el tratamiento de rásters fuera de las bases de datos geográficos en formato GRID.

Answer 1

Primera pregunta: ¿cuánto de esto está haciendo en Python? ¿Sólo estás llamando a herramientas de geoprocesamiento o estás haciendo una cantidad significativa de análisis numérico en Python? En el primer caso, es probable que los cuellos de botella se encuentren en las herramientas y que el uso de código nativo en el script no sea tan beneficioso como otras soluciones inteligentes. Si es lo segundo, entonces es posible que desee encontrar lo que es lento y hacerlo más rápido con mejores algoritmos, o posiblemente numpy, o alguna otra opción como se discute a continuación.

py2exe no en realidad compila tu código a x86/x64 nativo, sólo proporciona un ejecutable que incrusta tu script como bytecode y proporciona una forma mayormente portable de distribuirlo a usuarios sin Python en sus sistemas. Falló al intentar empaquetar arcgisscripting, por lo que no funcionó. Conseguir que py2exe funcione no mejorará el rendimiento.

Te recomiendo encarecidamente que utilices primero un perfilador para identificar los bits lentos y optimizar a partir de ahí. Existe un muy buen conjunto incorporado a Python Utilice cPerfil en una carrera larga para encontrar posibles lugares donde hacerla más rápida. A partir de ahí se puede optimizar secciones de distancia en C personalizado o posiblemente experimentar con pequeñas porciones como Cython Módulos .pyx.

Usted puede mirar en Cython para la posible construcción de toda la secuencia de comandos de Python como un módulo de extensión de código nativo, pero Psyco también puede ofrecerle un aumento del rendimiento con una barrera de entrada más baja.

Answer 2

No utilices una geodatabase personal sin una buena razón. Según nuestra experiencia, son sistemáticamente mucho más lentas que todas las demás formas de almacenamiento de datos de esri ( ref ). Aunque he leído un informe aquí en GIS.se que vio personal más rápido que el archivo gdb.

Cuando el flujo de trabajo consta de muchas iteraciones pequeñas, la llamada para crear el geoprocesador y comprobar una licencia suele ser la parte más costosa en tiempo del uso de python. Así que hacer todo lo que pueda, ya sea delante o detrás de gp = ... (o import arcpy en v10) es una técnica que utilizo mucho.

Con respecto a la compilación, esta cita lo dice mejor:

Cabe señalar que mientras se ejecuta un programa script [python] compilado es más rápido inicio tiempo (ya que no ne compilar), no ejecute más rápido.

Mark Cederholm tiene una presentación sobre el uso de ArcObjects en Python con algunas estadísticas sobre las operaciones de shapecopy (diapositiva nº 4). Python no sale muy bien parado, con un 32% de lo que se puede conseguir con C++ (VBA fue del 92%, VB y C# del 48%). No vayas corriendo y gritando demasiado rápido, muchas de las herramientas de geoprocesamiento son scripts python de todos modos (buscar c: \program fichiers \arcgis\ para '*.py').

Como muchos han dicho en otros foros, con Python el tiempo que se invierte en intentar optimizar el rendimiento compilando o escribiendo una función central en C o C++ a menudo empequeñece cualquier ganancia real de rendimiento (posiblemente) obtenida en tiempo de ejecución. Muchos dicen que el principal beneficio de Python es optimizar y mejorar desarrollador La atención humana es mucho más valiosa y costosa que el tiempo de procesamiento de las máquinas.

Answer 3

¿Cuánto tarda la delineación de la cuenca hidrográfica si se ejecuta desde las herramientas estándar de ArcToolbox en comparación con la versión de script? Si los tiempos son similares, entonces sospecho que no habrá ninguna mejora. Es posible que desee considerar la ejecución de procesos largos en segundo plano fuera de ArcMap.

Answer 4

No se puede compilar código python a código máquina. Cuando se ejecuta por primera vez, se compila a 'bytecode', un lenguaje intermedio (que crea archivos pyc)

py2exe envuelve los archivos dll requeridos por el intérprete y cualquier archivo python/externo requerido en un ejecutable. No se compila - el tiempo de ejecución no debería ser muy diferente.

Es posible hacer que el código Python se ejecute muy rápido, utilizando una combinación de diferentes técnicas.

Lo primero que debes hacer es perfilar tu código para encontrar los cuellos de botella. Una vez encontrados, suelo utilizar este proceso:

• Elimina los bucles 'for' utilizando matrices numpy o la función map(). Esto básicamente empuja el bucle a C.
• Investigar mejores implementaciones del algoritmo (esto va en paralelo con lo anterior). Cosas como reducir el número de operaciones de E/S, garantizar que se accede a los datos o que se almacenan en bloques contiguos.
• Trucos del intérprete, como evitar búsquedas costosas dentro de los bucles, evitar bloques "if" dentro de los bucles (utilizar "try" en su lugar).
• Perfil de nuevo
• Si sigue siendo demasiado lento, mira a empujar las partes críticas en C utilizando Cython (o escribir directamente en C, la creación de una DLL y el uso de ctypes para llamarlo)
• Perfil de nuevo
• Si sigue siendo demasiado lento, busque computación paralela o en la GPU (biblioteca de multiprocesamiento, pyCUDA, ParallelPython, etc.).

Answer 5

Si importas un script python desde otro lugar se genera un archivo .pyc. Por tanto, una forma sencilla de probar si la compilación marca la diferencia sería convertir tu script en una función (por ejemplo, main()). Si guardas ese script como example.py a continuación, cree otro archivo con las siguientes líneas:

import example
example.main() # call your script(s)

Si pruebas a ejecutarlo desde dentro del script, y a ejecutarlo cuando se importa, quizás puedas ver cuál es la diferencia. Esta es una forma de baja tecnología de hacerlo sin embargo.