地理处理速度测试的结果异常

我一直在观察Python地理处理脚本的异常性能。（附加的）脚本执行以下操作：

使用搜索光标查找与面要素相对应的UTM区域
根据搜索光标结果创建空间参考对象
将.csv转换为要素图层，然后转换为点要素类

根据脚本的运行方式，我注意到处理时间明显不同：

使用IDLE = 203秒的32位处理
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"

— 亚伦
source

单独导入arcpy需要多长时间？帖子中是否存在格式错误。是否应该尝试：在for循环内？

— 内森·W

我认为@NathanW的观点import arcpy是值得首先考虑的，因为看来您的三个测试的IDLE和64位路由仅需要时间，但是增加近两分钟似乎是多余的。尝试运行一个只不过会花费时间导入ArcPy的工具。

— PolyGeo

我可以很肯定地说这是import arcpy行。上次我使用arcpy时，从外部导入的速度很慢。ArcGIS会将其导入到其内部Python中，因此导入已被缓存。

— 弥敦道W

@Nathan和其他人绝对正确。当您调用“ import arcpy”时，通过IDLE或命令行运行进程会受到打击。但是，您可以在非常大的流程中进行权衡，通过改善性能获得时间。由于ArcGIS有效启动了另一个ArcMap会话，因此运行后台进程也很费时间。最后，您还需要在试用中消除其他变量，例如32位和64位计算机之间的硬件差异是什么，以及在试用期间其他哪些进程正在消耗资源等？

— MappaGnosis

+1 @JayLaura。可以进一步介绍。[ General python doc] [ docs.python.org/2/library/profile.html]和[ stackexchange posting] [ stackoverflow.com/questions/582336/…。

— 罗兰2014年

@Aaron：根据他的建议将我先前的评论重新发布为答案：

可以进一步介绍。[通用python文档]和[stackexchange发布]。

对听到他的发现绝对感兴趣。

— 罗兰
source

我有一个理论。

我认为问题可能是您的输出或输入的验证。在运行GP工具之前，arcpy会验证参数，例如，输出要素类是否已经存在。

在ArcMap中，工作空间（文件夹）的内容全部被缓存，并且可以针对目录的工作空间的“视图”（在内存中）快速进行验证。如果使用非ArcGIS工具添加数据集，则需要运行arcpy.RefreshCatalog（）来使目录视图与工作区（文件夹）的状态同步，这可能会造成混乱。

如果文件夹很大，并且您在ArcGIS之外运行，则arcpy可能每次都必须生成一个文件夹列表，以验证FeatureClassToFeatureClass输出。如果文件夹中有很多项目，这可能会变慢。

— 柯蒂斯·普莱斯
source