Résultats inhabituels pour les tests de vitesse de géotraitement

J'ai observé des performances inhabituelles avec un script de géotraitement Python. Le script (joint) effectue les actions suivantes:

Utilisez un curseur de recherche pour rechercher la zone UTM correspondant aux entités surfaciques
Créer un objet de référence spatiale basé sur les résultats du curseur de recherche
Convertir .csv en couche d'entités, puis en classe d'entités ponctuelles

J'ai remarqué des temps de traitement sensiblement différents en fonction de la façon dont le script est exécuté:

Traitement 32 bits avec IDLE = 203 secondes
Outil de script de premier plan de traitement 32 bits = 91 secondes
Outil de script d' arrière - plan de traitement 64 bits = 206 secondes

Pourquoi ce script fonctionnerait-il si différemment compte tenu des conditions ci-dessus? Je ne m'attendrais certainement pas à ce que l'outil de script 32 bits exécuté au premier plan soit 2 fois plus rapide que les autres méthodes.

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
source

Combien de temps faut-il pour importer arcpy tout seul? Y a-t-il une erreur de formatage dans le message. L'essai doit-il être dans la boucle for?

— Nathan W

Je pense que le point de @ NathanW import arcpyvaut la peine d'être considéré en premier car il semblerait que le temps ne soit requis que par les routes IDLE et 64 bits de vos trois tests, mais l'ajout de près de deux minutes semble excessif. Essayez d'exécuter un outil qui ne fait que chronométrer l'importation d'ArcPy.

— PolyGeo

Je serais assez sûr de dire que c'est la import arcpyligne. La dernière fois que j'ai utilisé arcpy, l'importation était lente depuis l'extérieur. ArcGIS aurait déjà importé cela dans son Python interne, donc l'importation est déjà mise en cache.

— Nathan W

@Nathan et les autres sont absolument corrects. L'exécution d'un processus via IDLE ou la ligne de commande prend un coup lorsque vous appelez «importer arcpy». Cependant, vous pouvez obtenir un compromis pour les très gros processus où vous récupérez le temps grâce à des performances améliorées. L'exécution d'un processus d'arrière-plan a également un impact sur le temps, car ArcGIS démarre efficacement une autre session ArcMap. Enfin, vous avez également d'autres variables que vous devez éliminer dans votre essai, telles que les différences de matériel entre vos machines 32 et 64 bits et quels autres processus consommaient des ressources pendant votre essai, etc.?

— MappaGnosis

+1 @JayLaura. Pourrait aller plus loin et profiler. [ General python doc] [ docs.python.org/2/library/profile.html] et [ stackexchange posting] [ stackoverflow.com/questions/582336/… .

— Roland

@Aaron: republier mon commentaire précédent comme réponse sur la base de ses conseils:

Pourrait aller plus loin et profiler. [Doc python général] et [publication stackexchange] .

Certainement intéressé à entendre ce qu'il trouve.

— Roland
source

J'ai une théorie.

Je pense que le problème peut être la validation de votre sortie ou de votre entrée. Avant l'exécution d'un outil GP, arcpy valide les paramètres, par exemple, si la classe d'entités en sortie existe déjà.

Dans ArcMap, le contenu de l'espace de travail (dossier) est entièrement mis en cache et la validation peut être effectuée par rapport à la "vue" du catalogue de l'espace de travail - en mémoire - rapidement. Cela peut être source de confusion si des jeux de données sont ajoutés à l'aide d'un outil non ArcGIS, nécessitant l'exécution d'un arcpy.RefreshCatalog () pour synchroniser la vue du catalogue avec l'état de l'espace de travail (dossier).

Si votre dossier est très volumineux et que vous exécutez en dehors d'ArcGIS, arcpy peut être amené à générer une liste de dossiers à chaque fois pour valider votre sortie FeatureClassToFeatureClass. S'il y a beaucoup d'éléments dans le dossier, cela pourrait vraiment devenir lent.

— Prix Curtis
source