ArcGIS Geoprocessing Tools kullanan Python betikleri (.exe'ye) derleniyor mu?


12

Birkaç aydır Python ile kod yazıyorum ve öncelikle coğrafi işlem görevleri için oldukça karmaşık bazı senaryolar geliştirdim. Bir SQL / VBA / VBScript arka planından geldiğim için hala çok şey öğreniyorum.

Derlenmiş kod genellikle bir dil yorumlayıcısı tarafından işlenmesi gereken koddan daha hızlı çalışır biliyorum, bu yüzden büyük veri ile çalışmak için bir .EXE dosyasına bir coğrafi işleme Python komut dosyası derleme olasılığı ile ilgileniyorum.

Bu mümkün mü? Öyleyse, arcgisscripting veya arcpy modüllerini içe aktaran bir Python (.py) komut dosyasını derlemenin en iyi yolu nedir?

Ne yapmak istediğimi bulmaya birkaç dakika harcadım ve arama bu makaleyi diğerleri arasında döndürdü: http://www.ehow.com/how_2091641_compile-python-code.html

Derleyici çalışıyor gibi görünüyordu, ancak ortaya çıkan .EXE dosyasını yürüttükten sonra, bazı dosyaların kullanılamadığını söyleyen şifreli bir hata verdi.

Python betiği, komut satırından oldukça iyi görünen şeyleri çalıştırıyor, ancak .py dosyasını derleyebilseydim biraz hafif bir gelişme görüp göremediğimi merak ediyorum. Yine, işlenmesi için +20 saat süren bazı büyük veri kümeleriyle çalışıyorum (havzaları girdi suyu kalitesi örnek sitelerinden ayırmak). İyileştirmelerden alabileceğim her şeyi alacağım.

Senaryo sitelerinin bir test seti kullanılarak komut satırından hızlı dışında ArcGIS% 10 koştu karşı ArcCatalog'da yeni araç kutusundaki bir komut aracı olarak senaryoyu kurma. Komut satırından herhangi bir ArcGIS örneğini adanmış bir makinede açmadan komut dosyasını çalıştırıyorum.

Peki, arcgisscripting modülünü içe aktaran ve ArcToolBox araçlarını çağıran Python betiklerini derlemek mümkün müdür?

DÜZENLE

Giriş için teşekkürler, bu benim için yararlı. Komut dosyası, çok sayıda ArcGIS aracını koordine etmenin ve istenen biçimlerde / konumlarda / uygun atıfta bulunmanın bir yoludur. Zaten bazı geçici raster dosyaları için bir çizik kişisel geodatabase yerine sıfırdan bir klasöre yazarak ESG GRID formatında IMG formatına karşı saklanabileceğini düşünüyorum bazı yağ kesilmiş. Yine de profiler önerilerine göz atacağım.

Ofisimde Python'un "derlenmiş kodun bir yorumlayıcıyla çalışan koddan çok daha hızlı" olduğunu söyleyen bazı sorular var. araçlar her iki şekilde de zaman alacaktır. Ve bugünkü bilgi işlem makinelerinde, yorumlanmış kodun, fazladan bir yol katetmeyi garanti etmek için derlenmiş koddan çok daha yavaş olmayabileceği anlaşılıyor.

EDIT - raster formatlarıyla programın optimizasyonu hakkında güncelleme.

Bu Python programının "optimizasyonunu" takip etmek istedim ve geçici bir rasterleri kişisel bir coğrafi veri tabanı yerine GRID formatına yazarak 2 saatlik işlem süresini tıraş edebildim. Sadece bu değil, veri boyutu disk alanı tüketiminde önemli bir azalma oldu. Tüm rasterleri yazdığım orijinal çalışma (ve sadece rasterlere dönüştürülen nokta özellikleri ve daha sonra havza rasterleri) sadece bu dosyalar için 37.1 GB veri ile sonuçlandı. Son iki veri çıkışının GRID formatında bir klasöre yazılması 667 MB veriye indirgenmiştir.

GDB dosyasının bu verileri nasıl ele alacağını merak ediyorum. Ancak, işleme süremi 9.5 saatten 7.5 saate düşürmek, kesinlikle GRID formatında coğrafi veri tabanlarının dışındaki rasterlerle uğraşmayı savunmak için yeterlidir.


Bu sabah ArcGIS Server Blog çok zamanında. Sterling @ esri neden ve ne zaman [burada] [1] [1]
Brad Nesom

Yanıtlar:


15

İlk soru: Python'da bunun ne kadarını yapıyorsunuz? Sadece Geoprocessing araçlarına mı sesleniyorsunuz yoksa Python'da önemli miktarda sayısal analiz mi yapıyorsunuz? Birincisi, darboğazlar muhtemelen araçlarda yaşıyor ve kodunuzda yerel kod kullanmak sizi diğer akıllı çözümler kadar satın almayacak. İkincisi ise, o zaman yavaş olanı bulmak ve daha iyi algoritmalar veya muhtemelen numpy veya aşağıda tartışıldığı gibi başka bir seçenekle daha hızlı hale getirmek isteyebilirsiniz.

py2exe gelmez aslında doğal x86 / x64 için kodunuzu derlemek, sadece bayt kodu Senaryonuzu gömer ve onların sistemlerinde Python olmadan kullanıcılara dağıtmadan bir çoğunlukla taşınabilir yol sağlayan bir yürütülebilir sağlar. Arcgisscripting'i paketlemeye çalışırken başarısız oldu, bu yüzden işe yaramadı. Aslında py2exe çalışma hala performans açısından hiçbir şey yapmaz.

İlk önce yavaş bitleri tanımlamak ve oradan optimize etmek için bir profiler kullanmanızı şiddetle tavsiye ederim. Python'da yerleşik çok iyi bir set var, daha hızlı hale getirmek için potansiyel yerleri bulmak için cProfile'ı uzun vadede kullanın. Buradan bölümleri özel C'ye optimize edebilir veya muhtemelen Cython .pyx modülleri olarak küçük bölümlerle deney yapabilirsiniz.

Muhtemelen tüm Python betiğini yerel bir kod genişletme modülü olarak oluşturmak için Cython'a bakabilirsiniz, ancak Psyco ayrıca giriş için daha düşük bir engelle performans artışı sağlayabilir.


4

ArcToolbox'taki standart araçlardan komut dosyası sürümüne kıyasla çalıştırıldığında havza tanımlaması ne kadar sürer? Zamanlar benzerse, o zaman iyileşme olmayacağından şüpheleniyorum. ArcMap dışındaki arka planda uzun işlemler çalıştırmayı düşünebilirsiniz.


Orijinal sorumu açıkladım ve hala olumlu bir evet / hayır cevabı almayı umuyorum, bu cevap sorumu cevaplamadığı için bu kodu derlemek mümkün.
turkishgold

2
@turkish Sorunuza doğrudan cevap vermeyebilir, ancak mükemmel bir öneri. Şansınız, sürecinizin tüm zamanını tanımlamada harcıyor olması iyidir, bu nedenle kodun değiştirilmesinin hiçbir miktarı kayda değer bir şekilde yardımcı olmaz. Bununla birlikte, algoritmanın yeniden düşünülmesi büyük bir fark yaratabilir. Yapmak istediğiniz ilk şeylerden biri, bu derleme yaklaşımıyla zamanınızı boşa harcıp harcamadığınızı görmek için mevcut yürütmeyi profillemektir.
whuber

1
@Dan ve @whuber ile hemfikirim. Bence daha derin bir analiz yapmak (yani kıyaslama ve profil oluşturma) performans iyileştirmeleri için sadece kaba kuvvet derleme yaklaşımından çok daha iyi bir fikir verecektir.
Jason Scheirer

4

İyi bir sebep olmadan kişisel bir coğrafi veritabanı kullanmayın. Deneyimlerimize göre, diğer tüm esri veri depolama biçimlerinden ( ref ) çok daha yavaştırlar . Gerçi burada GIS.se bir dosya gdb daha hızlı kişisel gördüm bir rapor okudum .

İş akışı birçok küçük yinelemeden oluştuğunda, jeoişlemciyi oluşturma ve bir lisansı kontrol etme çağrısı genellikle python kullanmanın en pahalı kısmıdır. Öyleyse önünüzde veya arkasında gp = ...(veya import arcpyv10'da) yapabildiğiniz kadar çok şey yapmak, çok kullandığım bir teknik.

Derleme ile ilgili olarak, bu alıntı en iyisini söylüyor:

Bir derlenmiş [piton] komut dosyası çalıştıran bir hızlı sahipken belirterek It değerinde başlatma (derlenmesini gerekmez gibi) zaman, o değil koşmak daha hızlı.

Mark Cederholm, Python'da ArcObjects'i şekil kopyalama işlemleri hakkında bazı istatistiklerle kullanma hakkında bir sunuma sahiptir (slayt # 4). Python çok iyi değil, C ++ ile elde edilebileceklerin% 32'sinde çalışıyor (VBA% 92, VB & C #% 48). Çok hızlı koşup çığlık atmayın, coğrafi işleme araçlarının çoğu yine de python komut dosyalarıdır ('* .py' için c: \ program files \ arcgis \ araması yapın).

Birçoğunun diğer mekanlarda söylediği gibi, python ile bir C veya C ++ çekirdek işlevini derleyerek veya yazarak performansı optimize etmeye harcanan zaman genellikle çalışma zamanında yapılan herhangi bir gerçek performans kazancını (muhtemelen) gölgede bırakır. Birçoğu, Python'un başlıca faydasının geliştirici süresini optimize etmek ve iyileştirmek olduğunu söylüyor ; İnsanın dikkati, makine işlem süresinden çok daha değerli ve pahalıdır.


1
Her açıdan evet. Param için, geliştirici zamanının en iyi kullanımı, darboğazları optimize etmek için Python'da, prototipte, C / C ++ 'a açılan prototip * kullanmaktır. * Prototip diyorum, ama biliyorum ki 'prototip'% 95 üretime geçecek.
Jason Scheirer

Python'daki ArcObjects üzerindeki bağlantılar için harika yorumlar ve teşekkürler. Bir GDB'ye yazmanın veri yönetimi perspektifinden şekil dosyasına (şekil dosyalarındaki özellik tablosu kısıtlamaları, özellik sınıfları, geometri gösterimi, genel veri yönetimi uygulamaları vb.) Ve daha kolay ve temiz yapabileceğiniz şeylere sahip olduğunu düşünüyorum. Access ortamına karşı DBF dosyalarıyla uğraşmak. Yani, temel olarak, yaptığınız şeyle ve çıktı verileriyle ne yapacağınızla maliyet-fayda dengesi. GDB dışındaki rastlayıcıların orta zemini ve GDB'deki diğer her şey çalışıyor gibi görünüyor.
turkishgold

1

Python kodunu makine koduna derleyemezsiniz. İlk kez çalıştırıldığında, bir ara dil (pyc dosyaları oluşturan) 'bayt kodu' için derlenir.

py2exe yorumlayıcı tarafından gereken dll dosyalarını ve gerekli python dosyalarını / harici dosyaları yürütülebilir bir dosyaya sarar. Derlenmemiştir - çalışma zamanı çok farklı olmamalıdır.

Farklı tekniklerin bir kombinasyonunu kullanarak Python kodunun çok hızlı çalışmasını sağlamak mümkündür.

Yapmanız gereken ilk şey, darboğazları bulmak için kodunuzun profilini oluşturmaktır. Bir kez bulunduğunda, genellikle bu işlemi kullanıyorum:

  • Numpy dizileri veya map () işlevini kullanarak 'for' döngülerini ortadan kaldırın. Bu temelde döngüyü C'ye iter.
  • Algoritmanın daha iyi uygulamalarını araştırın (bu tür yukarıdakilerle aynı anda gider). G / Ç işlemlerinin sayısını azaltmak, verilere bitişik bloklarda erişilmesini / depolanmasını sağlamak gibi şeyler.
  • Döngüler içinde pahalı aramalardan kaçınmak, ilmekler içinde 'if' engellemekten kaçınmak gibi yorumlayıcı 'püf noktaları' (bunun yerine 'try' kullanın)
  • Tekrar profil oluştur
  • Hala çok yavaşsa, kritik parçaları Cython kullanarak C'ye doğru itmeye bakın (veya doğrudan C'ye yazma, bir dll oluşturma ve onu çağırmak için ctypes kullanma)
  • Profil tekrar
  • Hala çok yavaşsa, paralel veya GPU hesaplamaya bakın (çoklu işlem kütüphanesi, pyCUDA, ParallelPython vb.)

0

Başka bir konumdan bir python betiği alırsanız, bu bir .pyc dosyası oluşturur. Bu nedenle, derlemenin bir fark yaratıp yaratmadığını test etmenin kolay bir yolu, komut dosyanızı bir işleve (örneğin main ()) dönüştürmek olacaktır. Bu komut example.pydosyasını farklı bir şekilde kaydederseniz, aşağıdaki satırlara sahip başka bir dosya oluşturun:

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

Komut dosyasının içinden çalıştığınızda ve içe aktarıldığında çalışıyorsanız, belki de farkın ne olduğunu görebilirsiniz. Bu, bunu yapmanın düşük teknolojili bir yoludur.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.