Незвичайні результати для тестів на швидкість геопроцедури

Я спостерігав незвичайні показники роботи із сценарієм обробки географічної обробки Python. Сценарій (додається) виконує такі дії:

Використовуйте курсор пошуку для пошуку зони UTM, що відповідає функціям багатокутника
Створіть просторовий довідковий об’єкт на основі результатів пошуку курсору
Перетворіть .csv у шар функції, а потім у точковий клас функцій

Я помітив помітно різні часи обробки залежно від того, як виконується сценарій:

32-бітна обробка за допомогою IDLE = 203 секунди
32-розрядний інструмент для обробки сценарію переднього плану = 91 секунда
64-розрядний інструмент для обробки фонового сценарію = 206 секунд

Чому цей сценарій може виконуватись так по-різному з огляду на вищезазначені умови? Я, звичайно, не сподівався, що 32-розрядний інструмент для скриптів, запущений на передньому плані, буде 2X таким же швидким, як і інші методи.

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?

— Натан Ш

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

— PolyGeo

Мені було б досить сміливо сказати, що це import arcpyлінія. Востаннє я використовував архпію, імпортував її ззовні. ArcGIS мав би те, що вже імпортується у свій внутрішній Python, тому імпорт вже кешований.

— Натан Ш

@Nathan та інші абсолютно коректні. Запуск процесу через IDLE або командний рядок вражає, коли ви викликаєте "імпортувати arcpy". Однак ви можете отримати компроміс за дуже великі процеси, де ви отримаєте час «назад» завдяки покращенню продуктивності. Запуск фонового процесу також вражає час, оскільки ArcGIS ефективно запускає ще один сеанс ArcMap. Нарешті, у вас також є інші змінні, які вам потрібно усунути під час випробування, наприклад, які відмінності в апаратному забезпеченні між вашими 32 та 64 бітовими машинами та якими іншими процесами витрачали ресурси під час випробування тощо?

— MappaGnosis

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

— Роланд

@Aaron: репостування мого попереднього коментаря як відповідь на основі його порад:

Могли б піти далі і профілем. [General python doc] та [stackexchange posting] .

Безумовно зацікавлений почути те, що він знаходить.

— Роланд
джерело

У мене є теорія.

Я думаю, що проблемою може бути перевірка вашого результату або вашого внеску. Перш ніж запускати інструмент GP, аркпія перевіряє параметри, наприклад, чи вже існує клас функції виводу.

В ArcMap вміст робочої області (папки) весь кешований, і перевірка може бути виконана на тлі швидкого "перегляду" робочої області каталогу - в пам'яті. Це може спричинити плутанину, якщо набори даних додаються за допомогою інструменту, що не належить до ArcGIS, вимагаючи запуску arcpy.RefreshCatalog () для синхронізації подання каталогу зі станом робочої області (папки).

Якщо ваша папка дуже велика, і ви працюєте за межами ArcGIS, можливо, arcpy повинен створювати папку, що перераховує кожен раз для перевірки результату FeatureClassToFeatureClass. Якщо в папці багато елементів, це дійсно може повільно.

— Кертіс Ціна
джерело