Компіляція сценаріїв Python (до .exe), які використовують інструменти для обробки даних ArcGIS?

Я кодую Python уже кілька місяців і розробив кілька досить складних сценаріїв, що стосуються головним чином завдань геообробки. Попри це, я все ще багато навчаюсь, оскільки я виходжу з фону SQL / VBA / VBScript.

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

Це навіть можливо? Якщо це так, то який найкращий спосіб скласти сценарій Python (.py), який імпортує модулі arcgiskcripting або arcpy?

Я витратив кілька хвилин на пошук того, що хочу зробити, і пошук повернув цю статтю серед інших: http://www.ehow.com/how_2091641_compile-python-code.html

Здавалося б, компілятор працює, але після виконання отриманого файлу .EXE він видав явну помилку, кажучи, що деякі файли недоступні.

Сценарій Python запускає те, що здається досить добре з командного рядка, але мені цікаво, чи можу я побачити незначне поліпшення, якщо мені вдалося скласти файл .py. Знову ж таки, я працюю з деякими великими наборами даних, на які витрачається +20 годин на обробку (відмежуючи вододіли від вхідних зразків якості якості води). Я візьму все, що можу, щоб покращити.

Сценарій пробіг на 10% швидше за межами ArcGIS з командного рядка, використовуючи тестовий набір сайтів проти налаштування сценарію як інструменту сценарію в новому інструментальному інструменті в ArcCatalog. Я запускав сценарій з командного рядка без будь-якого примірника ArcGIS, відкритого на спеціальній машині.

Отже, чи можливо компілювати сценарії Python, які імпортують модуль arcgisscripting та викликають інструменти ArcToolBox?

EDIT

Дякую за вклад, це корисно для мене. Сценарій багато в чому є способом координувати ряд інструментів ArcGIS та виводити в потрібних форматах / місцях / з відповідним атрибуцією. Я вже обрізав трохи жиру, я думаю, записуючи в папку "Скретч" замість особистої бази даних скретчів для деяких проміжних растрових файлів, щоб вони могли зберігатися у форматі ESRI GRID та форматі IMG. Я перевірю пропозиції профілерів, хоча.

У моєму кабінеті є хтось із запитань Python, що "компільований код набагато швидший, ніж код, що проходить через інтерпретатора", головним чином порівняно з, скажімо, складеною програмою Visual Basic або програмою VB.NET, але це хороший момент, що інструменти займуть час у будь-якому випадку. І, схоже, що в сучасних обчислювальних машинах, які інтерпретують код, може бути не набагато повільніше, ніж компільований код, що вимагає пройти цю відстань.

EDIT - оновлення щодо оптимізації програми за допомогою растрових форматів.

Хотіла слідкувати за моєю "оптимізацією" цієї програми Python, і мені вдалося поголити 2 години обробки часу, написавши проміжні растри у форматі GRID замість особистої бази даних. Мало того, було значне зменшення споживання дискового простору на розмір даних. У початковому виконанні я писав усі растрові (і вони були лише точковими функціями, перетвореними на растрові, а потім затоплені растри) привели до 37,1 ГБ даних саме для цих файлів. Запис двох останніх виходів даних у папку у форматі GRID було скорочено до 667 Мб даних.

Мені буде цікаво побачити, як файл GDB обробляє ці дані, хоча в основному за розміром даних. Але, скорочення мого часу на обробку з 9,5 годин до 7,5 годин, безумовно, достатньо, щоб відстоювати справу з растрами поза базами геоданих у форматі GRID.

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

py2exe насправді не компілює ваш код на рідний x86 / x64, він просто забезпечує виконуваний файл, який вбудовує ваш сценарій у байт-код і забезпечує переважно портативний спосіб його поширення серед користувачів без Python у своїх системах. Не вдалося при спробі поєднати аргскриптівку, через що це не вийшло. Насправді робота py2exe все ще не призведе до ефективної роботи.

Дуже настійно рекомендую спочатку скористатися профілером для виявлення повільних бітів та оптимізації звідти. У Python вбудований дуже гарний набір , використовуйте cProfile довгостроково, щоб знайти потенційні місця, щоб зробити його швидше. Звідти ви можете оптимізувати відібрані розділи у спеціальний C або, можливо, експериментувати з невеликими частинами як модулі Cython .pyx.

Ви можете розглянути Cython, можливо, будуючи весь скрипт Python як модуль розширення нативного коду, але Psyco також може дати вам підвищення продуктивності з нижчим бар'єром для входу.

Скільки часу має розмежування вододілу, якщо він працює зі стандартних інструментів ArcToolbox порівняно з версією сценарію? Якщо часи схожі, то я підозрюю, що поліпшення не буде. Ви можете розглянути можливість запуску довгих процесів у фоновому режимі поза ArcMap.

Не використовуйте персональну базу даних без поважних причин. На наш досвід вони постійно набагато повільніше, ніж усі інші форми зберігання даних esri ( ref ). Хоча я прочитав тут один звіт на GIS.se, який побачив швидше особистий, ніж файл gdb.

Коли робочий процес складається з безлічі невеликих ітерацій, заклик створити геопроцесор і перевірити ліцензію часто є найдорожчою частиною використання python. Отже, робити скільки завгодно перед або позаду gp = ...(або import arcpyв v10) - це одна з методик, яку я багато використовую.

Що стосується складання, ця цитата найкраще говорить:

Варто зазначити, що під час запуску компільованого сценарію [python] є швидший час запуску (оскільки його не потрібно компілювати), він не працює швидше.

У Марка Седерхольма є презентація про використання ArcObjects в Python з деякими статистичними даними щодо операцій з копіюванням (слайд №4). Python не спрацьовує дуже добре, працює на 32% від того, що можна досягти за допомогою C ++ (VBA склав 92%, VB & C # - 48%). Не бігайте і не кричіть занадто швидко, багато інструментів для геообробки все одно є скриптами python (шукайте c: \ program files \ arcgis \ for '* .py').

Як багато хто говорив на інших майданчиках, час, витрачений на python, намагаючись оптимізувати продуктивність, компілюючи або записуючи основну функцію C або C ++, часто глушить будь-які фактичні підвищення (можливо), досягнуті під час виконання. Багато хто каже, що головна перевага Python - це оптимізація та вдосконалення часу для розробників ; людська увага набагато цінніша і дорожча, ніж час машинної обробки.

Ви не можете компілювати код python до машинного коду. Коли він запускається вперше, він компілюється в "байт-код", проміжну мову (яка створює файли pyc)

py2exe перетворює файли dll, необхідні інтерпретатору, та будь-які необхідні файли python / зовнішні файли у виконуваний файл. Він не складений - час виконання не повинен сильно відрізнятися.

Можна змусити код Python працювати дуже швидко, використовуючи комбінацію різних методик.

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

• Усуньте циклі "for", використовуючи numpy масиви або функцію map (). Це в основному штовхає петлю на C.
• Досліджуйте кращі реалізації алгоритму (цей вид відповідає одночасно з вищезазначеним). Такі речі, як зменшення кількості операцій вводу / виводу, забезпечення доступу / зберігання даних у суміжних блоках.
• Інтерпретаторські "хитрощі", такі як уникнення дорогих пошукових запитів у циклі, уникання "if" блоків в циклі (замість цього, використовуйте "try")
• Профілюйте це ще раз
• Якщо це все ще занадто повільно, погляньте на просування критичних частин у C за допомогою Cython (або запис безпосередньо на C, створення dll та використання ctypes для його виклику)
• Знову профіль
• Якщо все ще занадто повільно, подивіться на паралельні чи графічні обчислення (багатопроцесорні бібліотеки, pyCUDA, ParallelPython тощо)

Якщо ви імпортуєте скрипт python з іншого місця, він генерує файл .pyc. Отже, одним із простих способів перевірити, чи компіляція має різницю, буде перетворити ваш скрипт у функцію (наприклад, main ()). Якщо ви збережете цей сценарій, example.pyтоді створіть інший файл із наступними рядками:

import example
example.main() # call your script(s)

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