Aumento de la velocidad de los scripts de Python usando arcpy

Actualización 4/11/2014

Parece que el script se estaba bloqueando en la herramienta Eliminar características, por lo que cambié a Truncar tabla, como se sugiere en la respuesta a continuación. También eliminé las variables no utilizadas de la herramienta de agregar.

Actualización 4/10/2014

Ejecuté este script en la computadora de mi compañero de trabajo (su máquina tiene más memoria Y contiene ArcGIS 10.0 / Python26) y se ejecutó rápidamente. ¡Hurra! Una vez que mi soporte técnico encuentre el CD ArcGIS 10.0, lo instalaré y probaré para ver si eso mejora la velocidad de mi máquina. Para ser claros, estamos ejecutando el mismo script, nuestra unidad de red y la conexión de la base de datos se asignan de manera idéntica, y las declaraciones de impresión son las mismas. Publicaré una actualización aquí una vez que eso suceda.

Fin de actualizaciones

Necesito aumentar la velocidad de algunos scripts de Python que realizan actualizaciones en una base de datos Oracle. Tuve estos scripts de Python funcionando bien durante un año o más, a través de tareas programadas y archivos por lotes para iniciar los scripts. La semana pasada me mudé de un XP a una máquina con Windows 7 y ArcGIS 10.0 -> 10.1. Desde entonces, los guiones se han vuelto terriblemente lentos. Si ejecuto este script usando una pequeña clase de entidad (que contiene ~ 20 entidades) se ejecuta en 30 segundos. Si uso una clase de entidad media (~ 80,000 registros) se ejecuta en 15 minutos. La clase de entidad que realmente necesito para poder transferir rápidamente contiene aproximadamente 1,000,000 de registros: el script solo llega hasta la declaración de impresión para verificar si existen los archivos (si la declaración en el código a continuación). Este proceso tardaría solo 35 minutos en completarse en mi máquina XP / ArcGIS 10.0.

A continuación se muestra el código simplificado con el que he estado probando. ¿Alguien tiene sugerencias sobre lo que puedo hacer para aumentar la velocidad? Gracias patty

import arcpy, os, sys
from arcpy import env
arcpy.env.overwriteOutput = True
from datetime import datetime
import smtplib
import string
import urllib

#Define variables
inWorkspace = "O:/LANDING_PAD/BOE/example.gdb" 
lpFeatures = inWorkspace + os.sep + "fc1"
outWorkspace =  "Database Connections\\THIS.sde"
arcpy.env.workspace = outWorkspace
workspace = ""
copyFC = outWorkspace + os.sep + "SDE.fc1_1" #The feature class the script will update via delete and append
schema_type = "NO_TEST"
fieldMappings = ""
subtype = ""
t = datetime.now()
print "This script began at: " + str(t)

if arcpy.Exists(lpFeatures) is True and arcpy.Exists(copyFC) is True:
    print "Both files exist. Beginning delete..."
    arcpy.DeleteFeatures_management(copyFC) #(copyFC)

    print "ALL DONE DELETING!"

    arcpy.Append_management(lpFeatures, copyFC, schema_type, fieldMappings, subtype) #Append data from landing pad to db
    print "ALL DONE APPENDING!"
    record_count = arcpy.GetCount_management(lpFeatures)
    print record_count
    r = datetime.now()
    print "This script ended at: " + str(r)

Primero quería comentar, pero luego me pareció más apropiado envolverlo para que fuera una respuesta (aunque pudiera estar incompleto).

Ejecuté su código en mi máquina (computadora portátil de hardware superior con SSD) agregando una clase de entidad de geodatabase de archivos a una clase de entidad de geodatabase de SQL Server en la misma máquina que me llevó unos 13 minutos. No puedo decir con certeza por qué la velocidad de ejecución difiere tanto en su entorno (10.0 >> 10.1), pero ha pedido sugerencias sobre qué puede hacer para aumentar la velocidad , así que aquí hay algunas ideas que podrían aumentar la velocidad de ejecutar el script.

1) Ejecuto el script desde la línea de comandos, lo que equivale a ejecutar un archivo .bat (ejecuto el script en el sabor de 64 bits, tengo instalado Python ArcGISx6410.2 de 64 bits).

c:\Python27\ArcGISx6410.2\python.exe c:\scripts\appendfc.py

Desde mi experiencia, generalmente es más rápido ejecutar la versión de 64 bits de Python para ejecutar operaciones GP largas y pesadas como Append. Por lo tanto, debe asegurarse de ejecutar esta versión de Python cuando ejecute el script.

2) No recomendaría usar arcpy.DeleteFeatures_management; es mucho más lento que ejecutar Truncate Table ya que este último no utiliza transacciones de base de datos, lo que mejora el rendimiento sobre la eliminación fila por fila.

Usted mencionó que el script solo llega hasta la declaración de impresión para verificar si los archivos existen (si la declaración en el código) . Existe una buena posibilidad de que siga eliminando fila por fila, lo que podría ser un proceso muy lento cuando accede a una tabla en una base de datos remota de Oracle (o realmente cualquier DBMS). Intente ejecutar el script con Truncar tabla, pero sin anexar primero solo para ver la diferencia de rendimiento en la etapa de eliminación.

3) Parece que estás usando "Database Connections\\THIS.sde"el código. Sin embargo, es mejor consultar el archivo de conexión en sí (archivo .sde) con el sistema de archivos o la ruta UNC, no con la carpeta de la ventana del catálogo "Conexiones de base de datos". Puede acceder al archivo .sde creado en C:\Users\%user%\AppData\Roaming\ESRI\Desktop10.1\ArcCatalog. Puede mover este archivo .sde según lo necesite y colocarlo en la carpeta a la que tendrá acceso el script Python.

4) En la arcpy.Append_managementfunción, utiliza un par de parámetros vacíos. En teoría, no debería hacer ninguna diferencia, pero sugeriría ejecutar la función sin especificar esos parámetros solo porque no los necesita. Nunca se sabe qué sucede detrás de escena y si esas cadenas vacías se evalúan en algún momento y si esto puede afectar el rendimiento. Simplemente siga arcpy.Append_management(lpFeatures, copyFC, schema_type)y no especifique parámetros para los que no proporcione ningún valor.

5) Desaliento el uso os.sepal crear una ruta a una clase de entidad. Úselo os.path.join(geodatabase,featureclassname)para eso en su lugar. Es simplemente más limpio y más legible.

Puede agregar más detalles a la pregunta después de haber probado las cosas anteriores y haber realizado algunas pruebas y revisión de código.

Un par de buenas preguntas para leer para obtener más información sobre cómo acelerar los scripts de Python en ArcGIS:

Rendimiento de ArcGISScripting y grandes conjuntos de datos espaciales

Geoprocesamiento en segundo plano (64 bits)

La herramienta Arcgis CopyFeatures es extremadamente lenta al exportar a SDE

Formas de acelerar los scripts de Python que se ejecutan como herramientas ArcGIS

Consideraciones de geoprocesamiento para datos de ArcSDE

Espero que este ejemplo ayude a responder la pregunta también y esté en un software más nuevo. Se basa en las respuestas y comentarios mencionados anteriormente.

Preparar:

1. Windows 7
2. SQL Server 2012 R2
3. ArcGIS 10.2.2 (servidor y escritorio)

La carga debía ser nocturna. Fue ~ 9300 registros y 234 atributos.

El modelo original estaba debajo y se realizó todo en SQL Server 2012 R2 / SDE (7 minutos a través de ArcCatalog y 3 horas con python):

1. Eliminar filas de la clase de entidad en SDE
2. Crear capa de evento XY desde la tabla en SQL Server
3. Agregar a la clase de entidad en SDE

Cómo lo modifiqué (10 segundos a través de ArcCatalog y 10 segundos a través de Python): •

1. Se reemplazó la herramienta para eliminar filas con la herramienta Truncar para la clase de entidad SIG en SDE
2. Exporte la tabla SQL a un FGDB en la unidad C local
3. Crear capa de evento XY en la memoria local
4. Clase de entidad a clase de entidad dentro de FGDB en la unidad C local
5. ENTONCES agregue la clase de entidad FGDB en SDE
6. Tenga en cuenta que mi base de datos de SQL Server está en la misma unidad C que mi FGDB. Puede ralentizarse un poco a través de una red, pero lo más probable es que no sean las 3 horas que estaba viendo.

Lo que sí ayudó un poco en el modelo original fue reemplazar las fuentes de datos según el # 3 recomendado anteriormente. Se afeitó 30 segundos cuando se ejecuta en ArcCatalog. Con python se afeitó unos 20 minutos. Por lo tanto, es una variable en velocidad, pero no es la variable más valiosa para abordar en mi caso. Parece que, según la mayoría de los blogs, a SQL Server simplemente no le gusta la carga de datos pesados ​​"desde la memoria" (es decir, hacer la capa de eventos xy). SQL / SDE parece preferir un objeto real para cargar. Esto explica por qué mis otras cargas que hago de la misma manera toman 1 minuto, pero esos son solo 1000 registros con 15 atributos, por lo que nunca cuestioné la eficiencia de mis modelos hasta que esta carga debía hacerse todas las noches. Como se mencionó, esta carga es de 9000 registros con 236 atributos.

El problema con el rendimiento entre 10.0 y 10.1 es que algo en las bibliotecas SDE se cambió en el escritorio. Solíamos publicar 1,000,000 por noche y solo demoramos 45 minutos, después de una actualización de software, tardó casi 24 horas. Obviamente no hay ningún problema con los datos y solo se cambió el software.

Verifique la versión de la geodatabase para asegurarse de que coincida con la versión del cliente que ejecuta arcpy. Informamos esto a ESRI sin respuesta o reconocimiento de un error. Es bastante obvio y el problema comenzó después de 10.0 SP1.

También otra prueba de copiar / pegar es más rápida que un apéndice intente esto desde 10.0 y 10.1 y el rendimiento debería ser similar. Esto demuestra que hay algún tipo de error en las versiones anteriores al agregar geometrías.