Mặc dù câu hỏi này đã được trả lời, tôi nghĩ rằng tôi có thể kêu vang trong việc đưa ra hai xu của mình.
TUYÊN BỐ TỪ CHỐI : Tôi đã làm việc cho ESRI tại nhóm GeoDatabase trong một số năm và chịu trách nhiệm duy trì các phần khác nhau của mã GeoDatabase (Phiên bản, Con trỏ, Chỉnh sửa, Lịch sử, Lớp học Mối quan hệ, v.v.).
Tôi nghĩ rằng nguồn lớn nhất của các vấn đề về hiệu năng với mã ESRI là không hiểu ý nghĩa của việc sử dụng các đối tượng khác nhau, đặc biệt là các chi tiết "nhỏ" của các tóm tắt GeoDatabase khác nhau! Vì vậy, rất thường xuyên, cuộc trò chuyện chuyển sang ngôn ngữ đang được sử dụng như là thủ phạm của các vấn đề hiệu suất. Trong một số trường hợp nó có thể được. Nhưng không phải lúc nào cũng vậy. Hãy bắt đầu với cuộc thảo luận ngôn ngữ và làm việc theo cách của chúng tôi.
1.- Ngôn ngữ lập trình mà bạn chọn chỉ quan trọng khi bạn đang làm một việc gì đó phức tạp, trong một vòng lặp chặt chẽ. Hầu hết thời gian, đây không phải là trường hợp.
Con voi lớn trong phòng là cốt lõi của tất cả các mã ESRI, bạn có ArcObjects - và ArcObjects được viết bằng C ++ bằng COM . Có một chi phí để giao tiếp với mã này. Điều này đúng với C #, VB.NET, python hoặc bất cứ thứ gì bạn đang sử dụng.
Bạn phải trả giá khi khởi tạo mã đó. Đó có thể là một chi phí không đáng kể nếu bạn chỉ làm một lần.
Sau đó, bạn phải trả giá cho mỗi lần tiếp theo bạn tương tác với ArcObjects.
Cá nhân, tôi có xu hướng viết mã cho khách hàng của mình bằng C #, vì nó dễ dàng và đủ nhanh. Tuy nhiên, mỗi khi tôi muốn di chuyển dữ liệu xung quanh hoặc thực hiện một số xử lý cho một lượng lớn dữ liệu đã được triển khai trong Công cụ địa lý, tôi chỉ khởi tạo hệ thống con tập lệnh và chuyển các tham số của mình. Tại sao?
- Nó đã được thực hiện. Vậy tại sao lại phát minh lại bánh xe?
- Nó thực sự có thể nhanh hơn . "Nhanh hơn viết nó bằng C #?" Vâng! Nếu tôi thực hiện, giả sử, tải dữ liệu theo cách thủ công, điều đó có nghĩa là tôi phải trả giá chuyển đổi bối cảnh .NET theo một vòng lặp chặt chẽ. Mỗi GetValue, Chèn, ShapeCopy đều có chi phí. Nếu tôi thực hiện một cuộc gọi trong GP, toàn bộ quá trình tải dữ liệu sẽ xảy ra trong quá trình thực hiện GP - trong C ++ trong môi trường COM. Tôi không trả giá cho việc chuyển đổi ngữ cảnh vì không có gì - và do đó nó nhanh hơn.
À đúng rồi, vậy thì giải pháp nếu sử dụng nhiều chức năng xử lý địa lý. Thật ra, bạn phải cẩn thận.
2. GP là một hộp đen sao chép dữ liệu (có thể không cần thiết) xung quanh
Nó là một con dao hai lưỡi. Đó là một hộp đen thực hiện một số phép thuật trong nội bộ và tạo ra kết quả - nhưng những kết quả đó rất thường được nhân đôi. 100.000 hàng có thể dễ dàng được chuyển đổi thành 1.000.000 hàng trên đĩa sau khi bạn chạy dữ liệu của mình thông qua 9 chức năng khác nhau. Chỉ sử dụng các hàm GP cũng giống như tạo mô hình GP tuyến tính, và ...
3. Xâu chuỗi quá nhiều hàm GP cho các bộ dữ liệu lớn rất kém hiệu quả. Mô hình GP tương đương (có khả năng) tương đương với thực hiện truy vấn theo cách thực sự thực sự thực sự ngu ngốc
Bây giờ đừng hiểu lầm tôi. Tôi yêu GP Model - nó tiết kiệm cho tôi khỏi việc viết mã mọi lúc. Nhưng tôi cũng nhận thức được rằng đó không phải là cách hiệu quả nhất để xử lý các bộ dữ liệu lớn.
Bạn đã từng nghe nói về Query Planner chưa? Công việc của bạn là xem xét câu lệnh SQL mà bạn muốn thực thi, tạo một kế hoạch thực hiện dưới dạng biểu đồ có hướng trông giống như một Mô hình GP , xem các số liệu thống kê được lưu trữ trong db và chọn nhiều nhất thứ tự tối ưu để thực hiện chúng . GP chỉ thực hiện chúng theo thứ tự bạn đặt mọi thứ vì nó không có số liệu thống kê để làm bất cứ điều gì thông minh hơn - bạn là người lập kế hoạch truy vấn . Và đoán xem? Thứ tự mà bạn thực hiện mọi thứ phụ thuộc rất nhiều vào tập dữ liệu của bạn. Thứ tự mà bạn thực hiện mọi thứ có thể tạo ra sự khác biệt giữa ngày và giây và đó là tùy thuộc vào bạn để quyết định.
"Tuyệt vời" bạn nói, tôi sẽ không tự viết kịch bản và cẩn thận về cách tôi viết nội dung. Nhưng bạn có hiểu trừu tượng GeoDatabase không?
4.Không hiểu trừu tượng GeoDatabase có thể dễ dàng cắn bạn
Thay vì chỉ ra từng điều có thể có thể gây ra cho bạn một vấn đề, hãy để tôi chỉ ra một vài lỗi phổ biến mà tôi thấy mọi lúc và một số khuyến nghị.
- Hiểu sự khác biệt giữa Đúng / Sai đối với con trỏ Tái chế . Cờ nhỏ bé này được đặt thành đúng có thể làm cho các đơn đặt hàng thời gian chạy nhanh hơn.
- Đặt bảng của bạn vào LoadOnlyMode để tải dữ liệu. Tại sao cập nhật chỉ mục trên mỗi chèn?
- Hiểu rằng mặc dù IWorkspaceEdit :: StartEditing trông giống nhau trong tất cả các không gian làm việc, chúng là những con thú rất khác nhau trên mỗi nguồn dữ liệu. Trên Enterprise GDB, bạn có thể có phiên bản hoặc hỗ trợ cho các giao dịch. Trên shapefiles, nó sẽ phải được thực hiện theo một cách rất khác. Làm thế nào bạn sẽ thực hiện Hoàn tác / Làm lại? Bạn thậm chí có cần phải kích hoạt nó không (vâng, nó có thể tạo ra sự khác biệt trong việc sử dụng bộ nhớ).
- Sự khác biệt giữa các hoạt động hàng loạt, hoặc hoạt động hàng đơn. Trường hợp tại điểm GetRow so với GetRows - đây là sự khác biệt giữa thực hiện truy vấn để có một hàng hoặc thực hiện một truy vấn để tìm nạp nhiều hàng. Một vòng lặp chặt chẽ với một cuộc gọi đến GetRow có nghĩa là hiệu suất khủng khiếp và nó là thủ phạm số 1 của các vấn đề về hiệu suất
- Sử dụng UpdateSearchedRows
- Hiểu sự khác biệt giữa CreatRow và CreateRowBuffer . Sự khác biệt lớn trong thời gian chạy chèn.
- Hiểu rằng IRow :: Store và IFeature :: Store kích hoạt các hoạt động đa hình siêu nặng . Đây có lẽ là lý do số 2 thủ phạm của hiệu suất thực sự chậm. Không chỉ lưu hàng, đây là phương pháp đảm bảo mạng hình học của bạn ổn, Trình soạn thảo ArcMap được thông báo rằng một hàng đã thay đổi, thông báo tất cả các lớp quan hệ có liên quan đến hàng này để xác thực chắc chắn rằng giá trị thẻ là hợp lệ, v.v. Bạn không nên chèn các hàng mới với điều này, bạn nên sử dụng một Chèn !
- Bạn có muốn (cần) thực hiện các thao tác chèn đó trong EditSession không? Nó làm cho một sự khác biệt rất lớn nếu bạn làm hay không. Một số thao tác yêu cầu nó (và làm mọi thứ chậm hơn), nhưng khi bạn không cần nó, hãy bỏ qua các tính năng hoàn tác / làm lại.
- Con trỏ là tài nguyên đắt tiền. Khi bạn đã xử lý một, bạn được đảm bảo rằng bạn sẽ có Tính nhất quán và Cách ly và điều đó có chi phí.
- Lưu trữ các tài nguyên khác như kết nối cơ sở dữ liệu (không tạo và hủy tham chiếu Vùng làm việc của bạn) và Bảng điều khiển (mỗi khi bạn mở hoặc đóng một tài khoản - cần phải đọc một số bảng siêu dữ liệu).
- Đặt FeatureClass bên trong hoặc bên ngoài FeatureDataset tạo ra sự khác biệt lớn về hiệu suất. Nó không có nghĩa là một tính năng tổ chức!
5.Và cuối cùng và không kém ...
Hiểu sự khác biệt giữa các hoạt động ràng buộc I / O và CPU
Tôi thành thật nghĩ về việc mở rộng nhiều hơn trên từng mục một và có thể thực hiện một loạt các mục blog bao gồm từng chủ đề đó, nhưng danh sách tồn đọng trong lịch của tôi chỉ tát vào mặt tôi và bắt đầu la hét với tôi.
Hai xu của tôi.