Obserwowałem niezwykłe wyniki za pomocą skryptu geoprzetwarzania Pythona. (Załączony) skrypt wykonuje następujące działania:
- Użyj kursora wyszukiwania, aby wyszukać strefę UTM odpowiadającą cechom wielokąta
- Utwórz przestrzenny obiekt odniesienia na podstawie wyników kursora wyszukiwania
- Konwertuj .csv na warstwę elementów, a następnie na punktową klasę elementów
Zauważyłem wyraźnie różne czasy przetwarzania w zależności od sposobu uruchamiania skryptu:
- Przetwarzanie 32-bitowe przy użyciu IDLE = 203 sekund
- Narzędzie skryptowe pierwszego planu przetwarzania 32-bitowego = 91 sekund
- 64-bitowe narzędzie skryptowe w tle przetwarzania = 206 sekund
Dlaczego ten skrypt miałby działać tak inaczej, biorąc pod uwagę powyższe warunki? Z pewnością nie spodziewałbym się, że 32-bitowe narzędzie skryptowe działające na pierwszym planie będzie dwa razy szybsze niż inne metody.
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
Jak długo zajmuje samo importowanie arcpy? Czy we wpisie wystąpił błąd formatowania? Czy spróbuj: być w pętli for?
—
Nathan W
Myślę, że
—
PolyGeo
import arcpywarto zwrócić uwagę na @NathanW, ponieważ wydaje się, że czas jest wymagany tylko przez IDLE i 64-bitowe trasy trzech testów, ale dodanie prawie dwóch minut wydaje się nadmierne. Spróbuj uruchomić narzędzie, które nie robi nic więcej niż czas importowania ArcPy.
Powiedziałbym, że to jest
—
Nathan W
import arcpylinia. Ostatnim razem, gdy korzystałem z arcpy, importowanie z zewnątrz było powolne. ArcGIS miałby to już zaimportowane w swoim wewnętrznym Pythonie, więc import jest już buforowany.
@Nathan i inni mają absolutną rację. Uruchamianie procesu za pomocą IDLE lub wiersza poleceń wymaga trafienia po wywołaniu polecenia „import arcpy”. Można jednak uzyskać kompromis w przypadku bardzo dużych procesów, w których czas „wraca” dzięki lepszej wydajności. Uruchomienie procesu działającego w tle również ma swoje znaczenie, ponieważ ArcGIS skutecznie rozpoczyna kolejną sesję ArcMap. Na koniec masz również inne zmienne, które musisz wyeliminować w trakcie procesu testowego, takie jak różnice w sprzęcie między komputerami 32- i 64-bitowymi i jakie inne procesy zużywały zasoby podczas procesu itp.?
—
MappaGnosis
+1 @JayLaura. Może pójść dalej i profilować. [
—
Roland
General python doc] [ docs.python.org/2/library/profile.html] i [ stackexchange posting] [ stackoverflow.com/questions/582336/… .