Resultados inusuales para pruebas de velocidad de geoprocesamiento

He estado observando un rendimiento inusual con un script de geoprocesamiento de Python. El script (adjunto) realiza las siguientes acciones:

Use un cursor de búsqueda para buscar la zona UTM correspondiente a las características del polígono
Crear objeto de referencia espacial basado en los resultados del cursor de búsqueda
Convierta .csv en capa de entidades y luego en una clase de entidad de puntos

He notado tiempos de procesamiento marcadamente diferentes en función de cómo se ejecuta el script:

Procesamiento de 32 bits usando IDLE = 203 segundos
Herramienta de script de primer plano de procesamiento de 32 bits = 91 segundos
Herramienta de script de fondo de procesamiento de 64 bits = 206 segundos

¿Por qué este script funcionaría de manera tan diferente dadas las condiciones anteriores? Ciertamente, no esperaría que la herramienta de script de 32 bits ejecutada en primer plano sea 2 veces más rápida que los otros métodos.

import arcpy, os, time

###IDLE Parameters
##fc = r'C:\path\to\polygon\fc\with\utm\zones\and\features'
##outws = r'C:\out\location'
##arcpy.env.workspace = r'C:\workspace'

####################
## Script tool parameters
fc = arcpy.GetParameterAsText(0)    # Feature class
outws = arcpy.GetParameterAsText(1) # Folder
arcpy.env.workspace = arcpy.GetParameterAsText(2)   # Workspace
####################

# Tables are .csv
tables = arcpy.ListTables()

start = time.clock()

# Look up which UTM zone .csv features are in
for t in tables:
    quad = t[7:17]
    print quad
    whereClause = """ "QUADID" LIKE '%s' """ % quad
    with arcpy.da.SearchCursor(fc, ("QUADID","ZONE"), whereClause) as cursor:
        for row in cursor:
            if row[0] == quad:
                utmZone = row[1]
                if utmZone == 10:
                    sr = arcpy.SpatialReference(26910)  # NAD_1983_UTM_Zone_10N
                elif utmZone == 11:
                    sr = arcpy.SpatialReference(26911)  # NAD_1983_UTM_Zone_11N
                elif utmZone == 12:
                    sr = arcpy.SpatialReference(26912)  # NAD_1983_UTM_Zone_12N
                elif utmZone == 13:
                    sr = arcpy.SpatialReference(26913)   # NAD_1983_UTM_Zone_13N
                else:
                    print "The UTM Zone is outside 10-13"
            else:
                pass

    # Convert .csv to feature class
    try:
        outLayer = "in_memory"
        # Now with the sr defined, create the XY Event Layer
        arcpy.MakeXYEventLayer_management(t, "x", "y", outLayer, sr, "z")
        arcpy.FeatureClassToFeatureClass_conversion(outLayer, outws, t[7:17])
        arcpy.Delete_management("in_memory")
        end = time.clock()
        print "In_memory method finished in %s seconds" % (end - start)

    except:
        # Print any error messages
        print arcpy.GetMessages(2)

print "Processing complete"

python arcgis-desktop arcpy geoprocessing arcgis-10.2 Aaron
fuente

¿Cuánto tiempo lleva importar arcpy solo? ¿Hay un error de formateo en la publicación? ¿Debería intentarlo: estar dentro del ciclo for?

Nathan W

Creo que vale la import arcpypena considerar primero el punto de @ NathanW porque parece que el tiempo solo es requerido por las rutas IDLE y 64bit de sus tres pruebas, pero agregar casi dos minutos parece excesivo. Intente ejecutar una herramienta que no hace más que importar la hora de ArcPy.

PolyGeo

Sería bastante seguro decir que es la import arcpylínea. La última vez que usé arcpy fue lento para importar desde afuera. ArcGIS tendría eso ya importado en su Python interno, por lo que la importación ya está en caché.

Nathan W

@Nathan y otros son absolutamente correctos. Ejecutar un proceso a través de IDLE o la línea de comandos recibe un golpe cuando llama 'import arcpy'. Sin embargo, puede obtener una compensación para procesos muy grandes en los que recupera el tiempo mediante un rendimiento mejorado. La ejecución de un proceso en segundo plano también tiene un impacto en el tiempo ya que ArcGIS comienza efectivamente otra sesión de ArcMap. Por último, también tiene otras variables que debe eliminar en su prueba, como cuáles son las diferencias de hardware entre sus máquinas de 32 y 64 bits y qué otros procesos consumieron recursos durante su prueba, etc.

MappaGnosis

+1 @JayLaura. Podría ir más allá y perfil. [ General python doc] [ docs.python.org/2/library/profile.html] y [ stackexchange posting] [ stackoverflow.com/questions/582336/… .

Roland

Tengo una teoria

Estoy pensando que el problema puede ser la validación de su salida o su entrada. Antes de que se ejecute una herramienta GP, arcpy valida los parámetros, por ejemplo, si la clase de entidad de salida ya existe.

Dentro de ArcMap, el contenido del espacio de trabajo (carpeta) se almacena en caché y la validación se puede realizar contra la "vista" del catálogo del espacio de trabajo, en memoria, rápidamente. Esto puede causar confusión si los conjuntos de datos se agregan utilizando una herramienta que no es ArcGIS, lo que requiere que se ejecute arcpy.RefreshCatalog () para sincronizar la vista del catálogo con el estado del espacio de trabajo (carpeta).

Si su carpeta es muy grande y se está ejecutando fuera de ArcGIS, es posible que arcpy tenga que generar una lista de carpetas cada vez para validar su salida FeatureClassToFeatureClass. Si hay muchos elementos en la carpeta, esto realmente podría ser lento.

Precio Curtis
fuente

Resultados inusuales para pruebas de velocidad de geoprocesamiento

Respuestas: