Niezwykłe wyniki testów prędkości geoprzetwarzania

Obserwowałem niezwykłe wyniki za pomocą skryptu geoprzetwarzania Pythona. (Załączony) skrypt wykonuje następujące działania:

1. Użyj kursora wyszukiwania, aby wyszukać strefę UTM odpowiadającą cechom wielokąta
2. Utwórz przestrzenny obiekt odniesienia na podstawie wyników kursora wyszukiwania
3. 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"

@Aaron: opublikowanie mojego wcześniejszego komentarza jako odpowiedzi na podstawie jego porady:

Może pójść dalej i profilować. [General python doc] and [stackexchange posting] .

Zdecydowanie zainteresowany usłyszeniem tego, co znajdzie.

Mam teorię.

Myślę, że problemem może być sprawdzenie poprawności wyników lub danych wejściowych. Przed uruchomieniem narzędzia GP, arcpy sprawdza parametry, na przykład, czy klasa obiektów wyjściowych już istnieje.

W ArcMap zawartość obszaru roboczego (folderu) jest buforowana, a sprawdzanie poprawności można wykonać w oparciu o „widok” katalogu obszaru roboczego - w pamięci - szybko. Może to powodować zamieszanie, jeśli zestawy danych zostaną dodane przy użyciu narzędzia innego niż ArcGIS, wymagając uruchomienia arcpy.RefreshCatalog () w celu zsynchronizowania widoku katalogu ze stanem obszaru roboczego (folderu).

Jeśli twój folder jest bardzo duży i pracujesz poza ArcGIS, może być konieczne wygenerowanie przez Arcpy listy folderów za każdym razem, aby sprawdzić poprawność danych wyjściowych FeatureClassToFeatureClass. Jeśli w folderze znajduje się wiele elementów, może to naprawdę spowolnić.