编译使用ArcGIS地理处理工具的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多个小时才能处理的大型数据集(从输入的水质采样点确定流域)。我会采取一切我可以改进的方式。

使用一组测试站点,从ArcCatalog的新工具箱中将脚本设置为脚本工具相比,从命令行在ArcGIS外将脚本运行速度提高了10%。我一直从命令行运行脚本,而没有在专用计算机上打开的任何ArcGIS实例。

因此,是否可以编译导入arcgisscripting模块并调用ArcToolBox工具的Python脚本?

编辑

感谢您的输入,这对我很有帮助。该脚本主要是一种协调许多ArcGIS工具并以所需格式/位置/具有适当属性的输出的方式。我认为通过写临时文件夹而不是临时栅格文件的临时个人地理数据库,可以减少一些麻烦,因此可以将它们存储为ESRI GRID格式和IMG格式。我将检查探查器的建议。

我办公室里有一些人对Python提出质疑主要是说与经过编译的Visual Basic程序或VB.NET程序相比,“经过编译的代码比通过解释器运行的代码要快得多”,但这是一个很好的观点,无论哪种方式,工具都将花费时间。而且,似乎对于当今的计算机而言,解释代码可能不会比编译后的代码慢那么多,以保证可以加倍努力。

编辑 -使用光栅格式更新程序的优化。

想跟进我对该Python程序的“优化”,并且通过将临时栅格写入GRID格式而不是个人地理数据库中,从而节省了2个小时的处理时间。不仅如此,数据大小的磁盘空间消耗显着减少。我最初编写所有栅格的过程(它们只是转换为栅格的点要素,然后是分水岭的栅格),仅这些文件就产生了37.1 GB的数据。将后两个数据输出以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

Answers:


15

第一个问题:您在Python中做了多少?您是在呼唤地理处理工具,还是在Python中进行大量的数值分析?如果是前者,则瓶颈可能存在于工具中,并且在脚本中使用本机代码不会像其他一些聪明的解决方法那样给您带来很多好处。如果是后者,则您可能希望找到较慢的速度,并使用更好的算法(或可能是numpy的)或以下讨论的其他一些选项使其更快。

py2exe 实际上并没有将您的代码编译为本机x86 / x64,它只是提供了一个可执行程序,该脚本将您的脚本嵌入为字节码,并提供了一种可移植的方式来将其分发给系统上没有Python的用户。尝试捆绑arcgisscripting时,它失败了,这就是为什么它不起作用的原因。实际上使py2exe仍然无法执行任何性能方面的工作。

我强烈建议您首先使用探查器来识别慢速位并从那里进行优化。Python内置了一个很好的集合,长期使用cProfile可以找到可能的地方以使其更快。在这里,您可以将部分优化为自定义C,也可以尝试使用Cython .pyx模块作为小部分。

您可以考虑使用Cython可能将整个Python脚本构建为本机代码扩展模块,但是Psyco可能还会为您带来性能提升和更低的进入门槛。


4

如果从ArcToolbox中的标准工具运行,与脚本版本相比,分水岭划定需要多长时间?如果时间相似,那么我怀疑不会有任何改善。您可能要考虑在ArcMap之外的背景中运行长进程。


我澄清了我的原始问题,希望仍能得到肯定的是/否答案,因为这种答案不能回答我的问题,因此可能会编译这样的代码。
turkishgold

2
@turkish它可能无法直接回答您的问题,但这是一个很好的建议。您的过程很可能会花所有时间在轮廓上,因此对代码进行少量调整将无济于事。但是,重新考虑算法可能会产生很大的不同。因此,您要做的第一件事就是分析当前执行情况,以查看您是否在浪费这种编译方法的时间。
whuber

1
我同意@Dan和@whuber。我认为,进行深入分析(即基准测试和性能分析)将比仅仅采用强力编译一切方法带来更好的性能改进见解。
詹森·谢勒

4

没有正当理由,请勿使用个人地理数据库。根据我们的经验,它们始终比所有其他形式的esri数据存储(ref)慢得多。虽然我在GIS.se上阅读了一份报告,但发现个人报告要快于文件gdb。

当工作流包含许多小迭代时,创建地理处理器并签出许可证的调用通常是使用python最为耗时的部分。因此,在前后gp = ...(或import arcpy在v10中)尽可能多地做是我经常使用的一种技术。

关于编译,这句话说得最好:

值得注意的是,虽然运行已编译的[python]脚本具有更快的启动 时间(因为它不需要编译),但运行速度不会更快。

马克· 塞德霍尔姆(Mark Cederholm)进行了有关在Python中使用ArcObjects的演示,并提供了一些有关shapecopy操作的统计信息(幻灯片#4)。Python表现不佳,运行速度仅为C ++的32%(VBA为92%,VB和C#为48%)。不要跑得太快,尖叫得太快,无论如何,许多地理处理工具都是python脚本(在c:\ program files \ arcgis \中搜索“ * .py”)。

就像许多人在其他地方所说的那样,使用python通过编译或编写C或C ++核心函数来优化性能所花费的时间通常使运行时获得的实际性能提升(可能)相形见war。许多人说Python的主要好处是优化和改善了开发时间。与机器处理时间相比,人类的关注更加宝贵和昂贵。


1
是的。用我的钱,开发人员时间的最佳用法是在Python *中创建原型*,基准测试,然后降级到C / C ++以优化瓶颈。*我说的是原型,但我知道95%的时间“原型”将投入生产。
詹森·谢勒

很棒的评论,也感谢您在Python中关于ArcObjects的链接。我认为,从数据管理角度来看,与shapefile(shapefile中的属性表限制与要素类,几何表示,总体数据管理实践等)相比,写入GDB的好处是,您可以在其中做得更轻松,更清洁访问环境与处理DBF文件的关系。因此,从根本上来说,成本与您正在做的事情以及您将要与输出数据做些什么有关。GDB之外的栅格以及GDB中其他所有栅格的中间地貌似乎都在起作用。
turkishgold

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文件。因此,一种简单的测试编译是否起作用的方法是将脚本转换为函数(例如main())。如果将该脚本另存为,example.py则用以下几行创建另一个文件:

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

如果您从脚本内部运行,并且在导入脚本时运行,那么您可能会发现有什么不同。不过,这是一种技术含量较低的方法。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.