ジオプロセシング速度テストの異常な結果

Pythonジオプロセシングスクリプトで異常なパフォーマンスを観測しています。（添付）スクリプトは、次のアクションを実行します。

検索カーソルを使用して、ポリゴンフィーチャに対応するUTMゾーンを検索します
検索カーソルの結果に基づいて空間参照オブジェクトを作成する
.csvをフィーチャレイヤーに変換してからポイントフィーチャクラスに変換する

スクリプトの実行方法に基づいて、処理時間が著しく異なることに気付きました。

IDLEを使用した32ビット処理= 203秒
32ビット処理フォアグラウンドスクリプトツール = 91秒
64ビット処理のバックグラウンドスクリプトツール = 206秒

上記の条件でこのスクリプトのパフォーマンスが異なるのはなぜですか？ フォアグラウンドで実行される32ビットスクリプトツールが他のメソッドの2倍の速さで動作することは期待できません。

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"

— アーロン
ソース

それだけでarcpyをインポートするのにどのくらい時間がかかりますか？投稿にフォーマットエラーがありますか？試すべき：forループの中に？

— Nathan W

import arcpy3つのテストのIDLEと64ビットルートでのみ時間が必要と思われるため、@ NathanWのポイントについて最初に検討する価値がありますが、2分近く追加するのは過度に思えます。ArcPyのインポートに時間をかけるだけのツールを実行してみてください。

— PolyGeo

私はそれがimport arcpyラインだと言ってもかなり安全でしょう。前回arcpyを使用したときは、外部からのインポートに時間がかかりました。ArcGISでは、内部Pythonに既にインポートされているため、インポートはすでにキャッシュされています。

— Nathan W

@Nathanと他の人は完全に正しいです。IDLEまたはコマンドラインを介してプロセスを実行すると、「import arcpy」を呼び出すとヒットします。ただし、パフォーマンスの向上によって時間を「取り戻す」非常に大規模なプロセスとのトレードオフを得ることができます。ArcGISが別のArcMapセッションを開始するため、バックグラウンドプロセスの実行にも時間がかかります。最後に、32ビットマシンと64ビットマシンのハードウェアの違いや、トライアル中にリソースを消費していた他のプロセスなど、トライアルで排除する必要のある他の変数もあります。

— MappaGnosis、2014年

+1 @JayLaura。さらに行くとプロファイル。[ General python doc] [ docs.python.org/2/library/profile.html]および[ stackexchange posting] [ stackoverflow.com/questions/582336/…。

— Roland、

@Aaron：彼のアドバイスに基づいて、以前のコメントを回答として再投稿します。

さらに行くとプロファイル。[一般的なPythonドキュメント]と[stackexchangeの投稿]。

彼が見つけたものを聞くことに間違いなく興味があります。

— ローランド
ソース

私には理論があります。

問題はあなたの出力または入力の検証かもしれないと思います。GPツールを実行する前に、arcpyはパラメーターを検証します。たとえば、出力フィーチャクラスが既に存在するかどうかなどです。

ArcMap内では、ワークスペース（フォルダー）のコンテンツがすべてキャッシュされ、メモリ内のワークスペースのカタログの「ビュー」に対して検証を高速に実行できます。これは、ArcGIS以外のツールを使用してデータセットを追加する場合に混乱を招く可能性があり、arcpy.RefreshCatalog（）を実行して、カタログビューをワークスペース（フォルダー）の状態と同期させる必要があります。

フォルダーが非常に大きく、ArcGISの外部で実行している場合、arcpyは、FeatureClassToFeatureClass出力を検証するために毎回フォルダーリストを生成する必要がある場合があります。フォルダに多くのアイテムがある場合、これは本当に遅くなる可能性があります。

— Curtis価格
ソース