Biên dịch tập lệnh Python (sang .exe) có sử dụng Công cụ xử lý địa lý ArcGIS không?

Tôi đã mã hóa bằng Python được vài tháng nay và đã phát triển một số tập lệnh hợp lý phức tạp cho các nhiệm vụ xử lý địa lý chủ yếu. Điều đó đang được nói, tôi vẫn đang học hỏi rất nhiều vì tôi đến từ nền tảng SQL / VBA / VBScript.

Tôi biết rằng mã được biên dịch thường chạy nhanh hơn mã phải được xử lý bởi trình thông dịch ngôn ngữ, vì vậy tôi quan tâm đến khả năng biên dịch tập lệnh Python xử lý địa lý thành tệp .EXE để làm việc với dữ liệu lớn.

Điều này thậm chí có thể? Nếu có, cách tốt nhất để biên dịch tập lệnh Python (.py) đang nhập các mô-đun arcgisscripting hoặc arcpy là gì?

Tôi đã dành vài phút để cố gắng tìm những gì tôi muốn làm và tìm kiếm đã trả lại bài viết này trong số những người khác: http://www.ehow.com/how_2091641_compile-python-code.html

Trình biên dịch dường như hoạt động, nhưng khi thực hiện tệp .EXE kết quả, nó đã báo lỗi khó hiểu cho biết một số tệp không khả dụng.

Tập lệnh Python chạy những gì có vẻ hợp lý từ dòng lệnh, nhưng tôi tự hỏi liệu tôi có thể thấy một số cải thiện nhỏ nếu tôi có thể biên dịch tệp .py không. Một lần nữa, tôi đang làm việc với một số bộ dữ liệu lớn đang mất hơn 20 giờ để xử lý (phân định các lưu vực sông từ các vị trí mẫu chất lượng nước đầu vào). Tôi sẽ lấy bất cứ thứ gì tôi có thể có để cải thiện.

Tập lệnh chạy nhanh hơn 10% bên ngoài ArcGIS từ dòng lệnh bằng cách sử dụng bộ trang web thử nghiệm so với thiết lập tập lệnh dưới dạng công cụ tập lệnh trong hộp công cụ mới trong ArcCatalog. Tôi đã chạy tập lệnh từ dòng lệnh với bất kỳ phiên bản nào của ArcGIS mở trên một máy chuyên dụng.

Vì vậy, có thể biên dịch các tập lệnh Python nhập mô-đun arcgisscripting và gọi các công cụ ArcToolBox không?

BIÊN TẬP

Cảm ơn cho đầu vào, điều này là hữu ích cho tôi. Kịch bản phần lớn là một cách để phối hợp một số công cụ ArcGIS và xuất ra các định dạng / vị trí mong muốn / với sự phân bổ thích hợp. Tôi đã giảm bớt một số chất béo Tôi nghĩ bằng cách ghi vào thư mục cào thay vì cơ sở dữ liệu địa lý cá nhân đầu cho một số tệp raster tạm thời để chúng có thể được lưu trữ ở định dạng ESRI GRID so với định dạng IMG. Tôi sẽ kiểm tra các đề xuất hồ sơ mặc dù.

Có một số người trong văn phòng của tôi hỏi Python rằng "mã được biên dịch nhanh hơn mã chạy qua trình thông dịch" chủ yếu so với chương trình Visual Basic đã biên dịch hoặc chương trình VB.NET, nhưng đó là một điểm tốt các công cụ sẽ mất thời gian. Và, có vẻ như với các máy tính ngày nay, việc giải thích mã có thể không chậm hơn nhiều so với mã được biên dịch để đảm bảo đi thêm một dặm nữa.

EDIT - cập nhật về tối ưu hóa chương trình với các định dạng raster.

Muốn theo dõi "tối ưu hóa" chương trình Python này của tôi và tôi đã có thể cạo 2 giờ thời gian xử lý bằng cách viết các trình quét tạm thời sang định dạng GRID thay vì cơ sở dữ liệu địa lý cá nhân. Không chỉ vậy, đã giảm đáng kể mức tiêu thụ không gian đĩa kích thước dữ liệu. Lần chạy đầu tiên tôi đã viết tất cả các trình quét (và chúng chỉ là các tính năng điểm được chuyển đổi thành các trình quét, và sau đó các trình quét lưu vực đầu nguồn) đã tạo ra 37,1 GB dữ liệu chỉ cho các tệp đó. Việc ghi hai dữ liệu đầu ra sau vào một thư mục ở định dạng GRID đã giảm xuống còn 667 MB dữ liệu.

Tôi tò mò muốn xem làm thế nào một tệp GDB sẽ xử lý các dữ liệu này mặc dù chủ yếu là về kích thước của dữ liệu. Nhưng, việc cắt giảm thời gian xử lý của tôi xuống từ 9,5 giờ xuống còn 7,5 giờ chắc chắn là đủ để ủng hộ việc xử lý các trình quét bên ngoài cơ sở dữ liệu địa lý theo định dạng GRID.

Câu hỏi đầu tiên: bạn đang làm bao nhiêu trong Python? Bạn chỉ đang gọi tới các công cụ Geoprocessing hay bạn đang thực hiện một số lượng đáng kể phân tích số trong Python? Nếu trước đây, các nút cổ chai có thể sống trong các công cụ và sử dụng mã gốc trong tập lệnh của bạn sẽ không mua cho bạn nhiều như một số cách giải quyết thông minh khác. Nếu sau này, bạn có thể muốn tìm thấy những gì chậm và làm cho nó nhanh hơn với các thuật toán tốt hơn, hoặc có thể numpy, hoặc một số tùy chọn khác như được thảo luận dưới đây.

py2exe không thực sự biên dịch mã của bạn thành bản gốc x86 / x64, nó chỉ cung cấp một tệp thực thi nhúng tập lệnh của bạn dưới dạng mã byte và cung cấp cách thức phân phối chủ yếu cho người dùng mà không cần Python trên hệ thống của họ. Nó đã thất bại khi cố gắng gói arcgisscripting, đó là lý do tại sao nó không hoạt động. Trên thực tế, việc py2exe hoạt động vẫn không làm được gì hiệu quả.

Tôi thực sự khuyên bạn trước tiên nên sử dụng một trình lược tả để xác định các bit chậm và tối ưu hóa từ đó. Có một bộ rất tốt được tích hợp sẵn trong Python , sử dụng cProfile trong một thời gian dài để tìm các vị trí tiềm năng để làm cho nó nhanh hơn. Từ đó bạn có thể tối ưu hóa đi phần vào tùy chỉnh C hoặc có thể thử nghiệm với các phần nhỏ như Cython module .pyx.

Bạn có thể xem xét Cython để có thể xây dựng toàn bộ tập lệnh Python dưới dạng mô-đun mở rộng mã gốc, nhưng Psyco cũng có thể cung cấp cho bạn một hiệu suất tăng với rào cản thấp hơn để nhập.

Việc phân định vùng đầu nguồn mất bao lâu nếu chạy từ các công cụ tiêu chuẩn trong ArcToolbox so với phiên bản tập lệnh? Nếu thời gian tương tự nhau, thì tôi nghi ngờ rằng sẽ không có cải thiện. Bạn có thể muốn xem xét việc chạy các quy trình dài trong nền bên ngoài ArcMap.

Đừng sử dụng cơ sở dữ liệu địa lý cá nhân mà không có lý do chính đáng. Theo kinh nghiệm của chúng tôi, chúng luôn chậm hơn nhiều so với tất cả các hình thức lưu trữ dữ liệu esri khác ( ref ). Mặc dù tôi đã đọc một báo cáo ở đây trên GIS.se thấy cá nhân nhanh hơn tệp gdb.

Khi quy trình công việc bao gồm nhiều lần lặp nhỏ, lệnh gọi để tạo bộ xử lý địa lý và kiểm tra giấy phép thường là phần tốn kém nhất khi sử dụng python. Vì vậy, làm nhiều nhất có thể ở phía trước hoặc phía sau gp = ...(hoặc import arcpytrong v10) là một kỹ thuật tôi sử dụng rất nhiều.

Liên quan đến việc biên dịch, trích dẫn này nói lên điều đó tốt nhất:

Điều đáng chú ý là trong khi chạy tập lệnh [python] đã biên dịch có thời gian khởi động nhanh hơn (vì nó không cần phải biên dịch), nó không chạy nhanh hơn.

Mark Cederholm có bài thuyết trình về việc sử dụng ArcObjects trong Python với một số thống kê về các thao tác tạo hình (slide # 4). Python không công bằng lắm, chạy ở mức 32% những gì có thể đạt được với C ++ (VBA là 92%, VB & C # ở mức 48%). Đừng chạy và la hét quá nhanh, nhiều công cụ xử lý địa lý là tập lệnh python (tìm kiếm tập tin c: \ chương trình \ arcgis \ cho '* .py').

Như nhiều người đã nói ở các địa điểm khác, với python, thời gian cố gắng tối ưu hóa hiệu suất bằng cách biên dịch hoặc viết hàm lõi C hoặc C ++ thường làm giảm bất kỳ hiệu suất thực tế nào (có thể) được thực hiện khi chạy. Nhiều người nói lợi ích chính của Python là tối ưu hóa và cải thiện thời gian của nhà phát triển ; sự chú ý của con người có giá trị và đắt đỏ hơn nhiều so với thời gian xử lý máy móc.

Bạn không thể biên dịch mã python thành mã máy. Khi nó chạy lần đầu tiên, nó được biên dịch thành 'bytecode', một ngôn ngữ trung gian (tạo các tệp pyc)

py2exe kết thúc các tệp dll theo yêu cầu của trình thông dịch và mọi tệp python / tệp bên ngoài cần thiết thành một tệp thực thi. Nó không được biên dịch - thời gian chạy không nên khác nhau nhiều.

Có thể làm cho mã Python chạy rất nhanh, sử dụng kết hợp các kỹ thuật khác nhau.

Điều đầu tiên bạn nên làm là lập hồ sơ mã của bạn để tìm ra các nút thắt cổ chai. Khi tìm thấy, tôi thường sử dụng quy trình này:

• Loại bỏ các vòng lặp 'cho' bằng cách sử dụng các mảng numpy hoặc hàm map (). Điều này về cơ bản đẩy vòng lặp vào C.
• Nghiên cứu thực hiện tốt hơn các thuật toán (loại này đồng thời với các thuật toán trên). Những thứ như giảm số lượng thao tác I / O, đảm bảo dữ liệu được truy cập / lưu trữ trong các khối liền kề.
• Thông dịch viên 'thủ thuật' như tránh tra cứu đắt tiền trong các vòng lặp, tránh 'nếu' chặn trong vòng lặp (sử dụng 'thử' thay thế)
• Hồ sơ một lần nữa
• Nếu vẫn còn quá chậm, hãy xem việc đẩy các phần quan trọng vào C bằng Cython (hoặc viết trực tiếp bằng C, tạo dll và sử dụng ctypes để gọi nó)
• Hồ sơ một lần nữa
• Nếu vẫn còn quá chậm, hãy xem tính toán song song hoặc GPU (thư viện đa xử lý, pyCUDA, ParallelPython, v.v.)

Nếu bạn nhập tập lệnh python từ một vị trí khác, nó sẽ tạo tệp .pyc. Vì vậy, một cách dễ dàng để kiểm tra xem việc biên dịch có tạo ra sự khác biệt hay không là biến tập lệnh của bạn thành một hàm (ví dụ: main ()). Nếu bạn lưu tập lệnh example.pyđó thì hãy tạo một tệp khác với các dòng sau:

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

Nếu bạn có thời gian chạy từ trong tập lệnh và chạy khi nó được nhập, có lẽ bạn có thể thấy sự khác biệt là gì. Đây là một cách công nghệ thấp để làm điều đó mặc dù.