ArcView 3.x Avenueビットマップ（タブ？）とArcView 10 Pythonカーソルの比較

注：この質問には答えがありますが、カーソル処理を最適化するためのヒントがあれば、大歓迎です。更新を監視します。

現在、上司（Avenueで働く）と私（Pythonで働く）はどちらも同じ問題を解決しようとしています。むしろ、私たちは両方ともそれを解決しましたが、私たちのソリューションが動作する速度は...控えめに言っても、バラバラです。彼のスクリプトが2時間で処理するものは、最大6です。ロジックの構文と実装の実際の違いは、3.xのビットマップと10.xのカーソルだけです。私たちは両方：

1）表1の値を保管します
。2）これらの値を使用して、表2の行を照会します
。3）表2の値を保管して、新しい行として表3に挿入します。

どちらのスクリプトでも、これらのプロセスは2つのネストされたループで完了します。コード最適化の素晴らしい世界を掘り下げる前に、AvenueスクリプトのパフォーマンスをPythonと比較すると、これは予期された出来事ですか？彼のスクリプトが操作時間の点で私のものを大幅に上回ったのはこれが初めてではないので、私は恐ろしいスクリプトを作成する前に気をつけるべきことがあるかどうかを知りたいのです。

これが無関係なビットを除いた私のスクリプトです：

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)

編集：これまでのいくつかのコメントを考えると、結合を使用してこれを行うより良い方法があるのではないかと思いますが、ブロブナジアン（今日の単語！）のサイズを考えると、疑わしいです。処理の中心は、1つのテーブルの情報を2番目のテーブルの一致するレコードに追加し、重要なフィールドのみを含む3番目のテーブルを作成することです。私はSDEを使用してこれを試したかったのですが、それは利用可能なオプションではないようです。考え？私の質問がいつもそれほど複雑である場合はお詫び申し上げますが、私は長年の煩わしさの底を突きとめようとしています。

回答済み：Jakubの単純な提案だけで、処理時間が500レコードあたり30秒から500レコードあたり3秒に短縮されました。すべての挿入で挿入カーソルを再開始すると、処理速度が大幅に低下します（明らかに）。これは、ArcView 3.xの速度に対抗するときに、このプロセスに対して行うことができる最適化ではないかもしれませんが、現時点では、これで十分です。さらなる提案は大歓迎です！

私はプログラミングの初心者ではありませんが、Pythonの初心者なので、これを少しずつお試しください...

copyRecord = arcpy.InsertCursor(outData)

For Nextループの前に挿入カーソルを設定しないでください。「out」データへのパスが「outData」変数に格納されている場合は、反復するたびにリセットする必要はないようです。これで物事が大幅にスピードアップすると思います。

私はあなたがArcPy、または9.3年頃のarcgisscriptingを使用していると想定します。どちらにしても、ここでのテクニックはあなたの処理をスピードアップします...多分あなたの上司より良いでしょう。

最初に、ルックアップを実行し、メモリ以外のメディアを使用して挿入すると、プロセスが遅くなります。Avenueはすばやく動作するように最適化されており、他のほとんどの言語よりもIOが本質的に速いC \ C ++（間違っている場合は修正してください）コードベースを使用しています。Pythonも（ArcPyやarcgisscriptingなどの操作を実行するためにCライブラリにフックする際にオーバーヘッドがある場合を除いて）高速です。

したがって、最初にこれを試してください
。1.メソッドを使用して、使用する必要があるテーブルをメモリにコピーします-

• gp.CopyFeatures（ "path to featureclass \ FeatureclassName"、 "'in_memory' \ FeatureclassName"）-フィーチャクラスの場合;
• gp.CopyRow（ "path to featureclass \ FeatureTableName"、 "'in_memory' \ FeatureTableName"）-'in_memory'フィーチャクラスまたはテーブルへのテーブル用。
  
  これにより、RAMディスクのようなメモリを使用できるようになり、ディスクのスラッシングを大幅に節約できます。また、FeatureDatasetパラメータを「in_memory」に置き換えることで、メモリ内にフィーチャクラスまたはテーブルを作成することもできます。

可能な限りPythonコンテナーを使用します。これにより速度も向上します。

最後に、ESRI形式の情報の読み取りと書き込みの効率の順序は次のとおりです。

1. シェープファイル（悲しいが本当）
2. パーソナルジオデータベース
3. ファイルジオデータベース
4. ArcSDE（直接接続でも遅い）

ここで機能するもののリストをgis.stackexchange.comでコンパイルしようとしているので、これらの提案を試してみてください。ここを参照してください

それは、AvenueがPythonより速いということではなく、ArcView3がArcGISよりも速いということです（あなたがしようとしていること）。

その音から、これは本質的に非空間的な演習であるため、dbfpyやodbc（自分で試したことがない）などのデータベーステーブルに直接アクセスして（たとえば、arcpyを使用しないで）実験することをお勧めします。個人的に、gdal / ogrスイートのコマンドラインogr2ogrは、arcgisの同等のトランザクションよりも桁違いに速いことがわかりました。私はOGRクエリ機能に軽く浸しただけで、Pythonバインディングのみを使用して何も構築していないため、その速度が引き継がれるかどうかはわかりません。

これは現時点では特に有用な回答ではありませんが、ArcGIS 10.1を待ちます。今年のesri devサミットで、arcpy 10.1カーソルサポートが完全に書き直され、大幅に高速化されたと言われました。プレナリー中に、速度が約8倍に向上したという主張がありました。