Необычные результаты для тестов скорости геообработки

Я наблюдал необычную производительность скрипта геообработки Python. (Прикрепленный) скрипт выполняет следующие действия:

Используйте поисковый курсор для поиска UTM-зоны, соответствующей объектам полигона
Создать объект пространственной привязки на основе результатов поиска курсора
Преобразование .csv в слой объектов, а затем в класс точечных объектов

Я заметил заметно разные времена обработки в зависимости от того, как выполняется скрипт:

32-битная обработка с использованием IDLE = 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?

— Натан W

Я думаю, что @ NathanW import arcpyзаслуживает рассмотрения в первую очередь, потому что может показаться, что время требуется только для IDLE и 64-битных маршрутов ваших трех тестов, но добавление почти двух минут кажется чрезмерным. Попробуйте запустить инструмент, который не делает ничего, кроме времени импорта ArcPy.

— PolyGeo

Я могу с уверенностью сказать, что это import arcpyлиния. В прошлый раз, когда я использовал arcpy, он медленно импортировал извне. В ArcGIS это уже импортировано во внутренний Python, поэтому импорт уже кэшируется.

— Натан W

@ Натан и другие абсолютно правы. Запуск процесса через IDLE или командную строку получает удар, когда вы вызываете import arcpy. Тем не менее, вы можете получить компромисс для очень крупных процессов, где вы получите время «назад» за счет повышения производительности. Запуск фонового процесса также имеет временную задержку, так как ArcGIS эффективно запускает другой сеанс ArcMap. Наконец, у вас также есть другие переменные, которые вам нужно исключить в ходе пробного периода, такие как различия в аппаратном обеспечении между вашими 32- и 64-битными машинами и какие другие процессы потребляли ресурсы во время пробного периода и т. Д.?

— MappaGnosis

+1 @JayLaura. Могли бы пойти дальше и профиль. [ General python doc] [ docs.python.org/2/library/profile.html] и [ stackexchange posting] [ stackoverflow.com/questions/582336/… .

— Роланд

@ Аарон: опубликовать мой предыдущий комментарий как ответ, основанный на его совете:

Могли бы пойти дальше и профиль. [Общие документы по Python] и [публикация stackexchange] .

Определенно интересно услышать, что он находит.

— Roland
источник

У меня есть теория.

Я думаю, что проблема может заключаться в проверке вашего вывода или вашего вклада. Перед запуском инструмента GP arcpy проверяет параметры, например, существует ли уже выходной класс объектов.

В ArcMap содержимое рабочей области (папки) все кэшируется, и проверка может быть проведена по каталогу «просмотр» рабочей области - в памяти - быстро. Это может привести к путанице, если наборы данных добавляются с использованием инструмента, не относящегося к ArcGIS, для запуска которого требуется arcpy.RefreshCatalog () для синхронизации представления каталога с состоянием рабочей области (папки).

Если ваша папка очень большая, и вы работаете вне ArcGIS, arcpy, возможно, придется каждый раз генерировать список папок для проверки вашего вывода FeatureClassToFeatureClass. Если в папке много элементов, это может замедлиться.

— Кертис Прайс
источник