ArcView 3.x Avenue Bitmaps (Registerkarten?) Im Vergleich zu ArcView 10 Python Cursors

Hinweis: Obwohl diese Frage eine Antwort enthält, sind weitere Tipps zur Optimierung eines Cursorprozesses sehr willkommen. Ich werde nach Updates suchen.

Derzeit versuchen mein Chef (der in Avenue arbeitet) und ich (der in Python arbeitet) beide, dasselbe Problem zu lösen. Vielmehr haben wir beide es gelöst, aber die Geschwindigkeit, mit der unsere Lösungen arbeiten, ist ... gelinde gesagt unzusammenhängend. Was sein Skript in 2 Stunden verarbeitet, kann bis zu 6 Stunden dauern. Der einzige wirkliche Unterschied in der Syntax und Implementierung in der Logik besteht in den Bitmaps von 3.x und den Cursors von 10.x. Wir beide:

1) Speichern Sie die Werte aus Tabelle 1.
2) Verwenden Sie diese Werte, um eine Zeile in Tabelle 2 abzufragen.
3) Speichern Sie die Werte aus Tabelle 2 zum Einfügen in Tabelle 3 als neue Zeile.

In beiden Skripten werden diese Prozesse in zwei verschachtelten Schleifen abgeschlossen. Ist dies ein zu erwartendes Ereignis, bevor ich mich mit der wunderbaren Welt der Codeoptimierung befasse, wenn ich die Leistung von Avenue-Skripten mit Python vergleiche? Dies ist nicht das erste Mal, dass seine Skripte meine in Bezug auf die Betriebszeit deutlich übertroffen haben. Daher würde ich gerne wissen, ob ich etwas beachten sollte, bevor ich mich für schreckliche Skripte kreuzige.

Hier ist mein Skript ohne überflüssige Teile:

import arcpy
import time
import sys
import os

def recordfindcopy(inFile,query,outFile):
    findRecord = arcpy.SearchCursor(inFile,query)
    for record in findRecord:
        copyRecord = arcpy.InsertCursor(outData) # <--- D'oh! (See answer)
        field = record.FIELD
        copy = copyRecord.newRow()
        copy.FIELD = field
        copyRecord.insertRow(copy)

StreetsFileList = [r"Path", 
                r"Path"]

for sfile in StreetsFileList:
    inStreets = sfile
    inTable = r"Path"
    outData = r"Path"
    fsaEntry = arcpy.SearchCursor(inTable)
    for row in fsaEntry:
        id = row.ID
        sQuery = "ID = %s " % (str(id))
        recordfindcopy(inStreets,sQuery,outData)

EDIT : Angesichts einiger der bisherigen Kommentare frage ich mich, ob es einen besseren Weg gibt, dies über Joins zu tun, obwohl ich angesichts der brobdingnagischen Größe (Wort des Tages!) Der Tabellen zweifelhaft bin. Das Herzstück der Verarbeitung besteht darin, Informationen aus einer Tabelle an übereinstimmende Datensätze in einer zweiten Tabelle anzuhängen und eine dritte Tabelle zu erstellen, die nur die wichtigen Felder enthält. Ich wollte dies mit SDE versuchen, aber das scheint keine verfügbare Option zu sein. Gedanken? Ich entschuldige mich, wenn meine Fragen immer so involviert sind , aber ich versuche, einem langjährigen Ärger auf den Grund zu gehen.

Beantwortet : Jakubs einfacher Vorschlag allein reduzierte die Verarbeitungszeit von 30 Sekunden pro 500 Datensätze auf 3 Sekunden pro 500 Datensätze. Das erneute Starten des Einfügecursors bei jeder Einfügung verlangsamte die Dinge erheblich (offensichtlich). Dies ist möglicherweise nicht die beste Optimierung, die man für diesen Prozess durchführen kann, wenn man die Geschwindigkeit von ArcView 3.x berücksichtigt. Für meine Zwecke reicht dies derzeit jedoch aus. Weitere Vorschläge sind herzlich willkommen!

Ich bin nicht neu in der Programmierung, aber sehr neu in Python, also nimm das mit einem Körnchen Salz ...

copyRecord = arcpy.InsertCursor(outData)

Sollte der Einfügecursor nicht vor der For Next-Schleife gesetzt werden? Mir scheint, wenn der Pfad zu den "out" -Daten in der Variablen "outData" gespeichert ist, muss er nicht jedes Mal zurückgesetzt werden, wenn Sie iterieren. Ich würde denken, dass dies die Dinge erheblich beschleunigen sollte.

Ich gehe davon aus, dass Sie ArcPy oder Arcgisscripting um 9.3 verwenden. In jedem Fall beschleunigen die Techniken hier Ihre Verarbeitung ... vielleicht besser als Ihre Chefs.

Das erste, was Sie tun müssen, ist das Nachschlagen und Einfügen mit einem anderen Medium als dem Speicher wird Ihre Prozesse verlangsamen. Avenue ist für eine schnelle Arbeit optimiert und verwendet eine C \ C ++ - Codebasis (korrigieren Sie mich, wenn ich mich irre), die bei E / A von Natur aus schneller ist als die meisten anderen Sprachen. Python ist auch schnell (genauso schnell), es sei denn, das Einbinden in c-Bibliotheken zur Ausführung von Vorgängen wie ArcPy oder Arcgisscripting ist mit einem Mehraufwand verbunden.

Versuchen Sie dies zuerst:
1. Kopieren Sie die Tabellen, die Sie verwenden müssen, mit den folgenden Methoden in den Speicher.

• gp.CopyFeatures ("Pfad zur Feature-Class \ Feature-Class-Name", "'in_memory' \ Feature-Class-Name") - für Feature-Classes und;
• gp.CopyRow ("Pfad zur Feature-Class \ FeatureTableName", "'in_memory' \ FeatureTableName") - für Tabellen in einer 'in_memory'-Feature-Class oder -Tabelle.
  
  Auf diese Weise können Sie Speicher wie RAM-Disk verwenden und viel Disk-Thrashing sparen. Sie können auch eine Feature-Class oder Tabelle im Speicher erstellen, indem Sie den Parameter FeatureDataset durch 'in_memory' ersetzen.

Verwenden Sie so oft wie möglich Python-Container. Dies erhöht auch die Geschwindigkeit.

Schließlich ist die Reihenfolge für Effizienz beim Lesen und Schreiben von Informationen für ESRI-Formate

1. Shapefile (traurig aber wahr)
2. Persönliche Geodatabase
3. Datei Geodatabase
4. ArcSDE (auch bei direkter Verbindung ist es langsamer)

Probieren Sie diese Vorschläge aus, da ich versuche, eine Liste der Dinge zusammenzustellen, die hier auf gis.stackexchange.com funktionieren. Siehe hier

Ich wette, es ist nicht so, dass Avenue schneller als Python ist, sondern dass ArcView3 schneller als ArcGIS ist (bei dem, was Sie versuchen zu tun).

Da dies vom Klang her im Wesentlichen eine nicht räumliche Übung ist, möchten Sie möglicherweise mit dem direkten Zugriff auf die Datenbanktabellen experimentieren (z. B. nicht arcpy verwenden), und zwar mit etwas wie dbfpy oder odbc (ich habe keines von beiden selbst ausprobiert). Persönlich habe ich festgestellt, dass die Befehlszeile ogr2ogr der gdal / ogr- Suite um Größenordnungen schneller ist als gleichwertige Transaktionen in arcgis. Ich habe mich jedoch nur leicht mit den OGR-Abfragefähigkeiten befasst und nichts mit nur den Python-Bindungen erstellt, sodass ich nicht weiß, ob sich diese Geschwindigkeit überträgt.

Dies ist im Moment keine besonders hilfreiche Antwort, aber warten Sie auf ArcGIS 10.1. Auf dem diesjährigen Esri Dev-Gipfel wurde uns mitgeteilt, dass die Unterstützung für arcpy 10.1-Cursor vollständig neu geschrieben wurde und erheblich schneller ist. Während des Plenums gab es einen Anspruch auf Geschwindigkeitsverbesserungen von etwa 8x.