Performances des scripts Python en tant qu'outil ArcGIS versus autonome

Quelqu'un a-t-il étudié la différence dans l'exécution d'un script Python dans ArcToolbox par rapport à un script autonome? J'ai dû écrire un script rapide et sale pour convertir un ensemble d'images RVB en bande unique en extrayant la bande 1. En tant que script autonome lisant et écrivant sur mon PC, il traite 1000 images de taille identique en environ 350 secondes. L'exécution du même script à partir d'ArcToolbox prend environ 1250 secondes.

import arcpy
import csv
from os import path

arcpy.env.workspace = in_folder
image_list = arcpy.ListRasters()

#Create a CSV file for timing output
    with open(outfile, 'wb') as c:
        cw = csv.writer(c)
        cw.writerow(['tile_name', 'finish_time'])

        #Start the timer at 0
        start_time = time.clock()

        for image in image_list:
            #Extract band 1 to create a new single-band raster
            arcpy.CopyRaster_management(path.join(image, 'Band_1'), path.join(out_folder, image))
            cw.writerow([image, time.clock()])

J'ai ajouté du code pour suivre la fin du traitement de chaque mosaïque et exporter les résultats au format CSV. La conversion de l'heure de fin en temps de traitement se produit dans Excel. Représentant graphiquement les résultats, le temps de traitement est à peu près le même pour chaque mosaïque qu'un script, mais le temps de traitement augmente linéairement lorsqu'il est exécuté en tant qu'outil ArcGIS.

Si les données sont lues et écrites sur un périphérique réseau, l'augmentation semble exponentielle.

Je ne cherche pas d'autres moyens d'accomplir cette tâche particulière. Je veux comprendre pourquoi les performances de ce script se dégradent au fil du temps lorsqu'il est exécuté en tant qu'outil ArcGIS , mais pas en tant que script autonome. J'ai également remarqué ce comportement avec d'autres scripts.

Voici ma vision des choses: l'exécution d'un script à partir d'ArcToolbox entraîne toutes sortes de coûts cachés car les outils tentent d'interagir / de mettre à jour l'application principale (ArcMap). Tous les outils mettront à jour les métadonnées, certains essaient de rafraîchir la fenêtre de carte et le MXD enregistre chaque outil que vous exécutez dans le panneau d'historique de géotraitement. Aucun de ces impacts cachés ne se produit lors de l'exécution dans un IDE.

Donc, exécuter une boucle à peine 1000 fois signifie que le MXD stocke 1000 journaux. Comme ArcMap est un logiciel propriétaire fermé, nous n'avons aucune idée de la façon dont la mécanique de l'enregistrement des journaux de traitement se déroule réellement et peut-être que l'étape de limitation de débit est la structure de données qu'ils ont utilisée n'est pas capable de gérer de grandes répétitions?

Un autre problème serait qu'ArcMap est une application pilotée par les événements, les choses se produisent lorsque des événements se produisent, vous effectuez un panoramique sur la carte et la carte s'actualise, vous ajoutez des données et un bouton permet. Je suppose qu'il est possible que les outils déclenchent toutes sortes d'événements et que l'application en soit "submergée" lorsque les outils sont utilisés de manière répétitive, mais c'est moi qui spécule?

Je pense qu'il faut monter les avantages et les inconvénients, exposer un script comme un outil de script le rend facile à utiliser dans l'environnement ArcMap, en particulier pour les utilisateurs non avertis. C'est un problème important si vous voulez que votre code soit adopté. Un nombre inconditionnel crunch juste par vous sans avoir besoin de faire un contrôle de qualité intermédiaire, puis exécutez le script dans votre IDE préféré.