Ho osservato prestazioni insolite con uno script di geoprocessing di Python. Lo script (allegato) esegue le seguenti azioni:
- Utilizzare un cursore di ricerca per cercare la zona UTM corrispondente alle funzioni del poligono
- Crea un oggetto di riferimento spaziale basato sui risultati del cursore di ricerca
- Converti .csv in feature layer e quindi in una feature class point
Ho notato tempi di elaborazione notevolmente diversi in base a come viene eseguito lo script:
- Elaborazione a 32 bit utilizzando IDLE = 203 secondi
- Strumento di script in primo piano con elaborazione a 32 bit = 91 secondi
- Strumento di script in background con elaborazione a 64 bit = 206 secondi
Perché questo script dovrebbe funzionare in modo così diverso date le condizioni di cui sopra? Di certo non mi aspetto che lo strumento di script a 32 bit eseguito in primo piano sia 2X più veloce degli altri metodi.
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"
1
Quanto tempo ci vuole per importare arcpy da solo? C'è un errore di formattazione nel post. Dovrebbe provare: essere all'interno del ciclo for?
—
Nathan W,
Penso che valga la
—
PolyGeo
import arcpypena di prendere in considerazione il punto di @ NathanW, perché sembrerebbe che il tempo sia richiesto solo dalle rotte IDLE e 64 bit dei tre test, ma l'aggiunta di quasi due minuti sembra eccessiva. Prova a eseguire uno strumento che non fa altro che importare ArcPy.
Sarei abbastanza sicuro di dire che è la
—
Nathan W,
import arcpylinea. L'ultima volta che ho usato arcpy è stato lento importarlo dall'esterno. ArcGIS l'avrebbe già importato nel suo Python interno, quindi l'importazione è già memorizzata nella cache.
@ Nathan e altri sono assolutamente corretti. L'esecuzione di un processo tramite IDLE o la riga di comando subisce un colpo quando si chiama "import arcpy". Tuttavia, è possibile ottenere un compromesso per processi molto grandi in cui si ottiene il tempo "indietro" attraverso prestazioni migliorate. L'esecuzione di un processo in background ha anche un successo temporale in quanto ArcGIS attiva l'avvio di un'altra sessione ArcMap. Infine, hai anche altre variabili che devi eliminare nella tua prova come quali sono le differenze hardware tra le tue macchine a 32 e 64 bit e quali altri processi consumavano risorse durante la tua prova, ecc.?
—
MappaGnosis,
+1 @JayLaura. Potrebbe andare oltre e profilo. [
—
Roland,
General python doc] [ docs.python.org/2/library/profile.html] e [ stackexchange posting] [ stackoverflow.com/questions/582336/… .