Tại sao tốc độ hiệu suất giữa ArcGIS và QGIS lại khác nhau như vậy?


17

Ok tôi không phải là một lập trình viên mà là một người sử dụng GIS thông minh. Tôi biết rằng QGIS được viết bằng C ++ và ArcGIS bằng ??? nhưng đối với hầu hết các nhiệm vụ của tôi gần đây, tôi luôn cố gắng sử dụng QGIS không chỉ vì nó miễn phí mà do thực tế là trải nghiệm Người dùng của nó rất tốt.

Tất cả các Gurus GIS ngoài đó bạn có thể cho tôi biết một số lý do cho sự khác biệt về tốc độ giữa hai hệ thống này không? Thành thật mà nói, tôi cảm thấy khó chịu khi sử dụng ArcGIS 10 do tốc độ của nó và tôi có một PC có RAM 8 GB.


3
Bạn có thể cung cấp thêm thông tin về những khía cạnh bạn thấy chậm không? Ví dụ, duyệt dữ liệu, phân tích raster, xử lý địa lý, v.v?
Stephen chì

Trải nghiệm chung là rất chậm .. tôi có nghĩa là thêm shapefiles ... mở arctoolbox, v.v.
GeoH2O

2
ArcGIS chắc chắn không được viết bằng .NET. Nó chủ yếu được viết bằng C ++ với rất nhiều nội dung khác được chốt trong ...
Devdatta Tengshe

1
@StephenLead, tôi đã ogr2ogrchạy nhanh hơn 36 lần so với Arcgis khi chuyển đổi shapefiles ( ref ). Tôi hy vọng QGIS sẽ chậm hơn một chút so với barebones ogr2ogr ở cùng một nhiệm vụ, nhưng không nhiều vì nó sử dụng ogr (bằng chứng là cả hai đều được chào đón).
matt wilkie

3
có lẽ cuộc trò chuyện lại: sự khác biệt tốc độ cụ thể có thể được thực hiện ở nơi khác, có lẽ là trò chuyện? chat.stackexchange.com/transcript/message/3510767#3510767
matt wilkie

Câu trả lời:


10

ArcGIS có vẻ rất bồng bềnh. Tôi nhớ một hiệu suất rất lớn khi chuyển từ Arcview 3.2 sang ArcGIS 8.0, và ở nhiều nơi nó vẫn tồn tại. Vào thời điểm đó, tôi nghĩ rằng nó có liên quan nhiều đến việc ESRI chuyển mã Arc / Info trước đó sang Windows và phải cắt giảm một số góc trong hiệu suất, nhưng tôi không chắc liệu điều đó có đúng không. Tôi nhớ rằng đã thấy một số ví dụ trên trang web này về các chức năng vẫn nhanh hơn đáng kể trong Arcview 3.3 so với ArcGIS 10. Điều này không liên quan gì đến thời gian khởi động, v.v. Và tôi không đồng ý với câu trả lời trước đó so với 'kỹ năng người dùng' '. Nhấp và chờ đợi không liên quan gì đến kỹ năng.

Tôi nghĩ rằng thực tế là ArcGIS không được viết với hiệu suất trong tâm trí và mỗi phiên bản tiếp tục cố gắng ném ngày càng nhiều chức năng hơn vào một nền tảng mã đã quá tải.


12

Tôi không quen thuộc với QGIS, nhưng tôi tự hỏi làm thế nào nó so sánh với ArcGIS về khả năng mở rộng. Thật không may, dường như có ít nhất một số sự đánh đổi giữa khả năng mở rộng và hiệu suất. Cách tốt nhất mà tôi tìm thấy để cảm nhận về khả năng mở rộng của ArcGIS là xem qua các loại thành phần COM của Esri được tìm thấy trong sổ đăng ký.

Mỗi danh mục đại diện cho một nơi mà người dùng có thể đăng ký dll chứa các lớp thực hiện giao diện Esri. Có rất nhiều loại. Các danh mục này cũng chứa thức ăn cho chó - Esri sử dụng chúng không chỉ để khám phá các tùy chỉnh của bên thứ 3, mà còn ngoài chức năng của hộp. Mặc dù điều này cung cấp một mức độ tùy biến rất mịn, nhưng điều đó cũng có nghĩa là tất cả những hạt mịn này cần được phát hiện và nạp vào thời gian chạy. Tôi không chắc chi phí tái định cư là bao nhiêu, nhưng nó phải đáng kể.

nhập mô tả hình ảnh ở đây

C:\Program Files (x86)\ArcGIS\Desktop10.0\Bin\Categories.exe

Khi bạn tạo một dll trong Visual Studio, có một nơi bạn có thể chỉ định địa chỉ cơ sở cho dll để tải vào. Vì có rất nhiều dll có kích thước khác nhau đang được tải biết trước điều này cho việc tùy chỉnh ArcObjects sẽ rất khó khăn. Tuy nhiên, tôi tự hỏi nếu một tập tin cấu hình có thể được tạo ra hướng dẫn nơi dll sẽ được tải vào bộ nhớ. Nếu vậy, một khi người dùng có arcmap chạy với các dll được tải mà anh ta thường sử dụng, anh ta có thể chạy một thói quen ghi địa chỉ cơ sở dll vào tệp cấu hình. Theo cách đó, khi arcmap bắt đầu, nó có thể tránh di chuyển bằng cách tải vào các địa chỉ đó. Sau đó, một lần nữa có thể với 64 bit này sẽ không thành vấn đề.

Tại 10.0 Esri đã giới thiệu Bổ trợ. Các danh mục bổ trợ nhỏ hơn nhiều và khám phá không phụ thuộc vào sổ đăng ký. Thay vào đó, các dll bổ trợ được nén và đặt trong một thư mục đã biết. Tôi không chắc làm thế nào điều này so sánh hiệu năng-khôn ngoan với các dll được phát hiện thông qua sổ đăng ký windows. Tôi nghĩ mục tiêu chính là cho phép cài đặt bởi những người không phải là quản trị viên.

Tôi giả sử câu hỏi đang đề cập đến sản phẩm Máy tính để bàn. Sản phẩm mới ArcGIS Runtime có trọng lượng nhẹ hơn nhiều. Tôi đã nghe nó được mô tả như là một sự thay thế cho MapObjects. Sẽ rất thú vị để xem nó phát triển như thế nào. Nếu Esri giới thiệu khả năng mở rộng cho WPF Runtime, tôi hy vọng họ không sử dụng cùng một cơ chế để khám phá được sử dụng bởi Visual Studio khi nó đưa vào danh sách các cụm. Lần đầu tiên nhấp vào "Thêm tài liệu tham khảo ..." đã bị chậm một cách đau đớn.


3
Tôi đã được một đại diện bán hàng của Esri nói rằng vài năm trước rằng Esri có thư viện COM lớn nhất trên trái đất, dễ dàng lớn hơn bất cứ thứ gì kể cả Microsoft đã xây dựng. Kể từ đó, tôi đã cho rằng một phần của sự chậm chạp của Arcgis Desktop đang tải tất cả thư viện đó cùng một lúc thay vì chỉ lấy các bit và phần cần thiết theo yêu cầu.
matt wilkie

@mattwilkie Thời gian khởi động cho ArcMap thường chậm hơn nhiều. Để cải thiện nó, họ đã giới thiệu các tiện ích mở rộng chỉ trong thời gian . Tôi không chắc chắn, nhưng tôi nghĩ rằng một cách tiếp cận tương tự được thực hiện với các đối tượng gx được tải khi bạn kích hoạt hộp thoại thêm dữ liệu lần đầu tiên.
Kirk Kuykendall

hmm Thời gian khởi động đối với tôi không nhanh hơn (nếu tôi đi từ bộ nhớ, không phải dữ liệu, vì vậy nó có thể chỉ là nhận thức). 17 giây từ khi nhấp vào nút Arcmap 10 trên Thanh tác vụ cho đến khi nó sẵn sàng làm điều gì đó (với điều thuật sĩ "tải bản đồ cuối cùng" đã tắt). Phiên thứ 2 khoảng 12s. Đây là sau khi thay thế đĩa cứng C: bằng SSD. Quantum mất 4s cho lần chạy đầu tiên và 2 giây cho lần chạy tiếp theo.
matt wilkie

@mattwilkie Vâng, đồng thời họ đã thêm các thanh công cụ mới, v.v., do đó, bất kỳ hiệu suất nào đạt được từ thời gian vừa qua có thể không hoàn toàn bù đắp cho sự chậm trễ do các tính năng phần mềm mới. Ngoài ra các yếu tố khác để xem xét: Nó có truy cập vào một máy chủ giấy phép? RAM bao nhiêu? Có nhanh hơn nếu bạn xóa / đổi tên normal.mxt của bạn không? (kiểm tra lần thứ hai sau khi xóa nó kể từ lần khởi động đầu tiên sẽ mất thời gian để tạo lại nó) Bạn đã cài đặt các tùy chỉnh chưa?
Kirk Kuykendall

1
Kirk: câu trả lời tuyệt vời. @mattwilkie: đó là sự thật. Tại thời điểm đó, Office Office có khoảng 400 (+?) Đối tượng COM. Tôi nghĩ rằng bây giờ, GeoDatabase tự nó có rất nhiều. Sự thật là tốt hơn hay tồi tệ hơn, ESRI đã phát điên lên một chút. Tôi nghĩ lúc đó, đó là một quyết định đúng đắn.
Ragi Yaser Burhum

8

Xin lỗi vì tôi đã phục hồi chuỗi, nhưng tôi có thể đưa ra một ví dụ cụ thể về trải nghiệm người dùng khác nhau như thế nào đối với ArcMap và QGIS.

Hôm nay tôi cần xây dựng một lưới điểm với khoảng cách 250 mét trên một quốc gia nhỏ, cắt lưới điểm thành đa giác biên giới quốc gia và liên kết các giá trị của một số trình quét với lưới điểm.

Trong ArcMap, điều này khiến tôi mất khoảng 10 phút, từ việc tải dữ liệu xuống bộ dữ liệu đã hoàn thành. Tại QGIS (Wroclaw), Chương trình đã bị sập hai lần chỉ khi cắt lưới với đa giác, sau đó chạy trong một giờ trước khi hoàn thành lần thử thứ ba. Đây là trên một hộp có 4 lõi kép và RAM 6Gb.

Tôi yêu QGIS và điều đó khiến tôi không thể sử dụng ArcMap, nhưng tôi thấy rất nhiều trường hợp sử dụng phổ biến trong đó QGIS không đáp ứng nhu cầu của tôi.

Bây giờ, nếu bất cứ ai có bất kỳ lời khuyên điều chỉnh hiệu suất nào có thể giải quyết khoảng cách hiệu suất này, tôi đều là tai.

Chris


đồng ý nhưng vì những gì đáng giá, tôi luôn luôn đổ về QGIS trước và nếu nó không hoạt động thì hãy quay lại ArcGIS
GeoH2O

1
Âm thanh như một lỗi với tôi. Tai nạn không phải là thước đo hiệu suất kém mà là triệu chứng của một cái gì đó sai. Báo cáo với người dân
củaISIS

Đối với một khu vực lớn như thế nào bạn đang xây dựng lưới điểm này? Chỉ cần chạy loại hoạt động tương tự trên 57 nghìn điểm trong QGIS (1.9) mà không gặp vấn đề gì.
Simbamangu

@Simbamangu đây là một hộp giới hạn xung quanh Honduras - khoảng nửa triệu điểm. tại Nicklas_Aven: Điểm lấy; nếu tôi có thời gian để sao chép một cách đáng tin cậy tôi sẽ nộp.
iamchriskelley

6

Tôi không nghĩ rằng Arc được viết bằng .NET. Arcobjects được viết bằng C ++. Arc có thể chậm hơn do sử dụng nhiều GUI, công cụ trợ giúp, tiện ích bổ sung, v.v ... QGIS là phần mềm tuyệt vời nhưng nó thiếu một số tính năng hữu ích có thể tốt cho người mới bắt đầu. Ngoài ra tôi không nghĩ rằng các công cụ rốn cơ bản trong ESRI (Arcobjects) chậm. Nó thường liên quan đến các kỹ năng của người dùng, nếu người dùng biết cách sử dụng Arc, điều đó không hề chậm chút nào. Có nói rằng, tôi cũng nên đề cập rằng mọi công cụ nên được xem xét trong từng trường hợp liên quan đến hiệu suất của nó. Một điều khác là, Arc là người đầu tiên trên trường GIS. Đầu tiên (tương đối với QGIS) luôn có lỗi và thế hệ tiếp theo tốt hơn một chút, trong trường hợp này nhanh hơn, nhưng tất cả đây chỉ là ý kiến ​​cá nhân của tôi.


2
Sidenote: Tôi nghi ngờ rằng ít nhất một phần lõi của ArcGIS vẫn được viết bằng Fortran (được đồn là nhanh như vậy, nếu không nhanh hơn, C đối với một số tác vụ số nhất định): Nếu bạn chạy ứng dụng bảng điều khiển .NET sử dụng ArcObjects và bạn nhấn Ctrl+Ctrong khi ArcObjects thực hiện một số thao tác, bạn sẽ nhận được thông báo từ thư viện thời gian chạy Fortran.
stakx

5
Ngoài ra, không đi sâu vào các chi tiết khó chịu về nitty, ArcObjects dựa trên COM , một trong những khung khả năng tương tác ban đầu và có gánh nặng hiệu suất riêng, đặc biệt là khi sắp xếp giữa mã được quản lý (ví dụ .NET) và mã không được quản lý (C ++).
blah238

4
@stakx Có mã trên cao trong mã Fortran đó, ít nhất là về phía raster (Spatial Analyst). Tôi đã phát triển các tiện ích bổ sung Fortran cho SA và thấy chúng luôn chạy nhanh hơn ít nhất năm lần. Trong những năm qua, các lớp của trình bao bọc trên các trình bao bọc trên các trình bao bọc đã được xây dựng để tích hợp mã gốc (cổ điển của thập niên 70 và 80) đã tạo ra gánh nặng ngày càng tăng đối với hiệu suất Arc *.
whuber

6

Điều này liên quan đến hiệu suất ArcGIS: ArcMap, ArcCatalog rất chậm để mở trên máy tính xách tay mới với nguồn tài nguyên dồi dào? mà có thể trong một phần tài khoản cho một số vấn đề hiệu suất. Chuỗi đó cho thấy cách phần cứng, mạng và cấu hình cấp phép có thể có ảnh hưởng đáng kể đến hiệu suất ArcGIS. Có thể, một số khác biệt được báo cáo về tốc độ có thể là do các yếu tố đó chứ không phải là sự khác biệt vốn có về khả năng.

(Được đăng dưới dạng liên kết câu trả lời, vì các bình luận có xu hướng bị mất.)


1
Trả lời và bình luận có mục đích khác nhau ở đây, Dan. Bạn nói đúng, các bình luận có trạng thái hạng hai. Một lý do là nhấn mạnh câu trả lời thực sự hữu ích. Bất cứ điều gì không phải là một câu trả lời nên là một nỗ lực để làm cho một câu hỏi có thể trả lời được hoặc để cải thiện một câu hỏi hoặc câu trả lời: đó là một nhận xét, ngay cả khi nó thực sự xuất sắc.
whuber

Đồng ý phiên bản trong phòng thí nghiệm của chúng tôi hoạt động tốt hơn phiên bản dùng thử mà tôi đang chạy trên PC của mình ...
GeoH2O

2

Tôi làm việc với dữ liệu cấp doanh nghiệp (ví dụ: dữ liệu quan tâm cho toàn bộ Thổ Nhĩ Kỳ) và đôi khi chỉ để kiểm tra dữ liệu, tôi cần kết xuất đó.

Nếu bạn muốn cải thiện hiệu suất của mình với ArcGIS, có vài điều mà tôi có thể khuyên;

Luôn sử dụng dữ liệu dự kiến. Sử dụng cơ sở dữ liệu địa lý hoặc ArcSDE với postgresql hoạt động hoàn hảo đối với tôi.

Sử dụng tập tin geodatabase và nếu có thể arcsde sẽ tăng tốc độ hoạt động của bạn. Trải nghiệm cá nhân của tôi với QGIS và ArcMap thực sự ngược lại. Vì phải mất gần vài phút để hiển thị 3 triệu điểm trên bản đồ. Mặt khác, ArcMap sẽ hiển thị chúng trong vòng vài giây.

Chỉ là ý kiến ​​của tôi.


Tại sao kết xuất 3 triệu điểm? Nếu bạn có nghĩa là lớp đó có 3 triệu điểm và một vài trong số đó nằm trong tầm nhìn của bạn, thì điều đó cũng nhanh chóng trong QGIS, nhưng bạn sẽ cần một chỉ số không gian. Nhưng tôi đồng ý rằng QGIS có thể khá khó để dừng lại khi bạn mắc lỗi cố gắng hiển thị quá nhiều hình học. Ngay cả khi giết kết xuất đồ họa với esc, các Geoemtries đôi khi vẫn bị treo ở đó.
Nicklas Avén
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.