ArcGIS Geoprocessing Toolsを使用するPythonスクリプトを(.exeに)コンパイルしますか?


12

私は数か月間Pythonでコーディングしており、主にジオプロセシングタスク用のかなり複雑なスクリプトを開発しました。そうは言っても、SQL / VBA / VBScriptのバックグラウンドから来ているので、私はまだ多くを学んでいます。

コンパイルされたコードは通常、言語インタープリターで処理する必要があるコードよりも高速で実行されることを知っているため、ビッグデータを操作するためにジオプロセシングPythonスクリプトを.EXEファイルにコンパイルする可能性に興味があります。

これも可能ですか?もしそうなら、arcgisscriptingまたはarcpyモジュールをインポートするPython(.py)スクリプトをコンパイルする最良の方法は何ですか?

やりたいことを見つけるために数分を費やし、検索の結果、とりわけこの記事が返されました:http : //www.ehow.com/how_2091641_compile-python-code.html

コンパイラは動作しているように見えましたが、結果の.EXEファイルを実行すると、一部のファイルが利用できないという不可解なエラーが発生しました。

Pythonスクリプトは、コマンドラインからはかなり適切と思われるものを実行しますが、.pyファイルをコンパイルできた場合、若干の改善が見られるかどうか疑問に思っています。繰り返しますが、処理に+20時間かかる大きなデータセットを使用しています(入力水質サンプルサイトからの分水界の輪郭を描く)。改善のために手に入れることができるものは何でも取ります。

このスクリプトは、サイトのテストセットを使用してコマンドラインから迅速外のArcGISの10%を走っ ArcCatalogで新しいツールボックスのスクリプトツールとしてスクリプトを設定します。専用のコンピューターでArcGISのインスタンスを開かずに、コマンドラインからスクリプトを実行しました。

では、arcgisscriptingモジュールをインポートし、ArcToolBoxツールを呼び出すPythonスクリプトをコンパイルできますか?

編集

入力をありがとう、これは私にとって有用です。このスクリプトは、主に多くのArcGISツールを調整し、適切な属性で目的の形式/場所で出力する方法です。一部の暫定ラスターファイルのスクラッチパーソナルジオデータベースではなくスクラッチフォルダーに書き込むことで、ESRI GRID形式とIMG形式の両方で保存できるように、すでにいくつかの脂肪を削除しました。ただし、プロファイラーの提案を確認します。

私のオフィスには、主にコンパイルされたVisual BasicプログラムやVB.NETプログラムと比較して、「コンパイルされたコードはインタープリターを介して実行されるコードよりもはるかに速い」と Pythonに質問する人がいますが、それは良い点ですツールはどちらの方法でも時間がかかります。そして、現代のコンピューティングマシンでは、コードの解釈はコンパイルされたコードよりもそれほど遅くないので、その余分な距離を進むことが保証されているようです。

編集 -ラスター形式でのプログラムの最適化に関する更新。

このPythonプログラムの「最適化」をフォローアップしたかったため、パーソナルジオデータベースではなくGRID形式で中間ラスターを書き込むことで、2時間の処理時間を節約できました。それだけでなく、データサイズのディスクスペース消費量が大幅に削減されました。私がすべてのラスターを書き込んだ元の実行(およびそれらはラスターに変換されたポイントフィーチャであり、その後、流域ラスターであった)は、これらのファイルだけで37.1 GBのデータになりました。後者の2つのデータ出力をGRID形式のフォルダーに書き込むことは、667 MBのデータに削減されました。

主にデータのサイズの方法で、ファイルGDBがこれらのデータをどのように処理するかを知りたいと思います。ただし、処理時間を9.5時間から7.5時間に短縮することで、GRID形式のジオデータベース外のラスターを処理することを支持できます。


今朝のArcGIS Serverブログは非常にタイムリーです。ESRI @スターリングは、なぜ、いつアウトラインの良い仕事し[1] [1]:[ここを。] blogs.esri.com/Dev/blogs/arcgisserver/archive/2011/04/12/...
ブラッドNesom

回答:


15

最初の質問:Pythonでこれをどのくらい行っていますか?ジオプロセシングツールを呼び出しているだけですか、それともPythonで大量の数値解析を行っていますか?前者の場合、ボトルネックがツールに存在する可能性が高く、スクリプトでネイティブコードを使用しても、他の巧妙な回避策ほど購入することはできません。後者の場合、遅いアルゴリズムを見つけて、より良いアルゴリズム、またはおそらくnumpy、または以下で説明する他のオプションを使用して高速化することができます。

py2exe 実際にコードをネイティブのx86 / x64にコンパイルするのではなく、スクリプトをバイトコードとして埋め込む実行​​可能ファイルを提供するだけで、システムにPythonがないユーザーにそれを配布するための移植性の高い方法を提供します。arcgisscriptingをバンドルしようとしたときに失敗したため、機能しませんでした。実際にpy2exeを動作させても、パフォーマンスに関しては何もしません。

最初にプロファイラーを使用して低速ビットを特定し、そこから最適化することを強くお勧めします。Pythonには非常に優れたセットが組み込まれています。cProfileを長期的に使用して、高速化する潜在的な場所を見つけてください。そこからセクションをカスタムCに最適化するか、Cython .pyxモジュールとして小さな部分を試すことができます。

Pythonスクリプト全体をネイティブコード拡張モジュールとして構築する可能性についてはCythonを調べることができますが、Psycoはエントリの障壁を低くしてパフォーマンスを向上させることもできます。


4

スクリプトバージョンと比較して、ArcToolboxの標準ツールから実行した場合、分水界の描写にはどれくらい時間がかかりますか?時間が似ている場合、改善はないと思われます。ArcMapの外部でバックグラウンドで長いプロセスを実行することを検討することをお勧めします。


私は元の質問を明確にしましたが、この答えが私の質問に答えないので、そのようなコードをコンパイルすることは可能ですか?
トルコゴールド

2
@turkishそれはあなたの質問に直接答えないかもしれませんが、それは素晴らしい提案です。プロセスがすべての時間を線引きに費やしている可能性が高いので、コードを微調整してもそれほど助けにはなりません。ただし、アルゴリズムを再考すると、大きな違いが生じる可能性があります。したがって、最初に行うことの1つは、現在の実行をプロファイルして、このコンパイルアプローチで時間を無駄にしているのかどうかを確認することです。
whuber

1
@Danと@whuberに同意します。徹底的な分析(つまり、ベンチマークとプロファイリング)を行うと、単に総当たり的なすべてをコンパイルするアプローチよりも、パフォーマンスの向上に関する洞察がはるかに得られると思います。
ジェイソンシャイラー

4

正当な理由がない限り、パーソナルジオデータベースを使用しないでください。私たちの経験では、それらは他のすべての形式のesriデータストレージ(ref)より一貫してずっと遅いです。私はここでGIS.seでファイルgdbよりも個人の方が速いというレポートを1つ読んでいますが。

ワークフローが多数の小さな反復で構成される場合、ジオプロセッサを作成してライセンスをチェックアウトする呼び出しは、多くの場合、Pythonを使用する上で最も時間のかかる部分です。したがって、できる限り多くのことを前または後ろgp = ...(またはimport arcpyv10)で行うことは、私がよく使うテクニックの1つです。

コンパイルに関しては、この引用は最も良いと言っています:

コンパイル済みの[python]スクリプトを実行すると起動 時間が速くなります(コンパイルする必要がないため)が、実行速度は速くなりません。

Mark Cederholmが、シェープコピー操作に関するいくつかの統計とともに、PythonArcObjectsを使用する方法について説明しています(スライド#4)。Pythonはあまり公平ではなく、C ++で達成できるものの32%で実行されます(VBAは92%、VBとC#は48%)。実行して叫びすぎないでください。ジオプロセシングツールの多くはとにかくPythonスクリプトです(c:\ program files \ arcgis \で「* .py」を検索してください)。

他の場所で多くの人が言っているように、Pythonでは、CまたはC ++コア関数をコンパイルまたは記述することでパフォーマンスを最適化しようとするのに費やした時間は、実行時に行われる実際のパフォーマンスの向上をd小化します。Pythonの主な利点は、開発者の時間を最適化および改善することです。人間の注意は機械の処理時間よりもはるかに価値があり高価です。


1
はい、すべての点で。開発者の時間の最適な使用法は、Pythonでプロトタイプを作成し、ベンチマークを作成し、C / C ++にドロップダウンしてボトルネックを最適化することです。*私はプロトタイプと言いますが、私は95%の時間で「プロトタイプ」がそれを実稼働に移行することを知っています。
ジェイソンシャイラー

PythonのArcObjectsのリンクに対するすばらしいコメントと感謝。GDBへの書き込みには、データ管理の観点とシェイプファイル(シェイプファイルの属性テーブルの制限とフィーチャクラス、ジオメトリ表現、全体的なデータ管理プラクティスなど)からのメリットがあるだけでなく、より簡単に、よりクリーンにできることもあると思いますAccess環境とDBFファイルの処理。そのため、基本的に、あなたがしていることと、出力データで何をしなければならないかとの費用対効果のトレードオフです。GDBの外側のラスターとGDBのその他すべてが機能しているようです。
トルコゴールド

1

Pythonコードをマシンコードにコンパイルすることはできません。初めて実行するときは、中間言語(pycファイルを作成する)である「バイトコード」にコンパイルされます。

py2exeは、インタープリターに必要なdllファイルと、必要なpythonファイル/外部ファイルを実行可能ファイルにラップします。コンパイルされていません-ランタイムに大きな違いはありません。

さまざまな手法を組み合わせて使用​​して、Pythonコードを非常に高速に実行することができます。

最初にすべきことは、コードをプロファイリングしてボトルネックを見つけることです。見つかったら、通常このプロセスを使用します。

  • numpy配列またはmap()関数を使用して「for」ループを削除します。これは基本的にループをCにプッシュします。
  • アルゴリズムのより良い実装を調査します(この種のアルゴリズムは上記と並行して行われます)。I / O操作の数を減らし、データが連続したブロックにアクセス/保存されるようにすること。
  • ループ内での高価な検索の回避、ループ内での「if」ブロックの回避などの「トリック」の解釈(代わりに「try」を使用)
  • もう一度プロファイル
  • それでも遅すぎる場合は、Cythonを使用して重要な部分をCにプッシュする(またはCで直接記述し、dllを作成してctypesを使用して呼び出す)ことを検討してください
  • もう一度プロファイル
  • それでも遅い場合は、並列またはGPUコンピューティング(マルチプロセッシングライブラリ、pyCUDA、ParallelPythonなど)を見てください

0

別の場所からpythonスクリプトをインポートすると、.pycファイルが生成されます。したがって、コンパイルが違いを生むかどうかをテストする簡単な方法の1つは、スクリプトを関数(たとえば、main())に変えることです。そのスクリプトを保存する場合example.py、次の行を含む別のファイルを作成します。

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

スクリプト内から実行し、インポート時に実行すると、違いが何であるかを見ることができます。ただし、これはローテクの方法です。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.