Waarom is de prestatiesnelheid tussen ArcGIS en QGIS zo anders?

Oké, ik ben geen programmeur maar een productieve GIS-gebruiker. Ik weet dat QGIS is geschreven in C ++ en ArcGIS in ??? maar voor de meeste van mijn taken probeer ik de laatste tijd altijd QGIS niet alleen te gebruiken omdat het gratis is, maar vanwege het feit dat de gebruikerservaring zo goed is.

Alle GIS-goeroes die er zijn, kun je me een paar redenen voor het verschil in snelheid tussen deze twee systemen vertellen? Eerlijk gezegd doet het me pijn om ArcGIS 10 te gebruiken vanwege zijn snelheid en ik heb een pc met 8 GB RAM.

17
Welkom bij GIS SE! In uw antwoord lijkt u de vraag "Waarom is de prestatiesnelheid tussen ArcGIS en QGIS zo anders?" Niet aan te pakken. en in plaats daarvan alleen een tourmeting van de QGIS 2.6-prestaties vermelden. Daarom ga ik het omzetten in een opmerking.
toegevoegd de auteur UnkwnTech, de bron
Klinkt eerder als een pleidooi dan als een vraag
toegevoegd de auteur Dave Anderson, de bron
@StephenLead, ik heb ogr2ogr 36 maal sneller geklokt dan Arcgis bij het converteren van shapefiles ( ref ). Ik verwacht dat QGIS een beetje langzamer is dan barebones ogr2ogr voor dezelfde taak, maar niet zozeer omdat het ogr gebruikt (bewijs is hoe dan ook welkom).
toegevoegd de auteur Greg, de bron
misschien conversatie: specifieke snelheidsverschillen kunnen elders worden uitgevoerd, misschien chat? chat.stackexchange.com/transcript/message/3510767#3510767
toegevoegd de auteur Greg, de bron
Kunt u meer informatie geven over welke aspecten u traag vindt? Bijvoorbeeld bladeren naar gegevens, rasters analyseren, geoprocessen, enz.?
toegevoegd de auteur Henry Taylor, de bron
ArcGIS is zeker niet geschreven in .NET. Het is meestal geschreven in C ++ met een heleboel andere dingen vastgebout op ...
toegevoegd de auteur Henrik, de bron
De algemene ervaring is erg traag .. ik bedoel het toevoegen van shapefiles ... openen arctoolbox enz
toegevoegd de auteur Cell-o, de bron
Nu werken de QGIS 2.6 erg snel, zelfs met shp-bestanden. Bijvoorbeeld, QGIS render shp-bestand met ongeveer 500000 polygonen gedurende 7 seconden bij de eerste keer en gedurende 3 seconden bij de tweede.
toegevoegd de auteur Felix Ruzzoli, de bron

6 antwoord

Ik ben niet zo bekend met QGIS, maar ik vraag me af hoe het zich verhoudt tot ArcGIS in termen van uitbreidbaarheid. Helaas lijkt er op zijn minst enige afweging te zijn tussen uitbreidbaarheid en prestaties. De beste manier om de ArcGIS-uitbreidbaarheid te leren kennen, is door een kijkje te nemen op Esri's COM-componentcategorieën gevonden in het register.

Elke categorie vertegenwoordigt een plaats waar gebruikers dll's kunnen registreren die klassen bevatten die een Esri-interface implementeren. Er zijn een lot van categorieën. Deze categorieën bevatten ook hondenvoer - Esri gebruikt ze niet alleen om aanpassingen door derden te ontdekken, maar ook uit van de doosfunctionaliteit. Hoewel dit een zeer fijnmazig niveau van aanpassing biedt, betekent dit ook dat al deze fijne korrels tijdens runtime moeten worden ontdekt en geladen. Ik weet niet zeker wat de kosten van verhuizing zijn, maar deze moet aanzienlijk zijn.

enter image description here

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

Wanneer u een dll in Visual Studio maakt, is er een plaats waar u het basisadres kunt opgeven voor de dll om in te laden. Aangezien er zoveel dll's van verschillende groottes worden geladen, weet dit van te voren voor een ArcObjects-aanpassing heel moeilijk zou zijn. Toch vraag ik me af of er een configuratiebestand kan worden gemaakt waarin wordt aangegeven waar de dll in het geheugen moet worden geladen. Als dat zo is, zodra een gebruiker arcmap draait met de geladen dll's die hij normaal gesproken gebruikt, zou hij een routine kunnen uitvoeren die de dll-basisadressen naar een configuratiebestand zou schrijven. Op die manier kan arcmap verhuizing voorkomen door in die adressen te laden. Dan opnieuw misschien met 64 bit dit maakt niet uit.

Om 10.0 introduceerde Esri invoegtoepassingen. De categorieën invoegtoepassingen zijn veel kleiner en detectie is niet afhankelijk van het Windows-register. In plaats daarvan worden de dll's voor invoegtoepassing gezipt en in een bekende map geplaatst. Ik weet niet zeker hoe dit prestatiegewijze wordt vergeleken met dll's die zijn ontdekt via het Windows-register. Ik denk dat het hoofddoel was om installatie door niet-beheerders toe te staan.

Ik ga ervan uit dat de vraag verwijst naar het Desktop-product. Het nieuwe product ArcGIS Runtime is veel lichter. Ik heb het horen beschrijven als een vervanging voor MapObjects. Het zal interessant zijn om te zien hoe het evolueert. Als Esri uitbreidbaarheid voor wpf Runtime introduceert, hoop ik dat ze niet hetzelfde mechanisme gebruiken voor ontdekking dat wordt gebruikt door Visual Studio wanneer het de lijst met assembly's aanvult. Die eerste keer klikken op "Referentie toevoegen ..." is pijnlijk traag geworden.

12
toegevoegd
@mattwilkie Ja, tegelijkertijd hebben ze nieuwe werkbalken etc. toegevoegd, dus eventuele prestatiewinsten van just-in-time hebben waarschijnlijk niet volledig gecompenseerd voor vertragingen als gevolg van nieuwe softwarefuncties. Ook andere factoren om te overwegen: heeft het toegang tot een licentieserver? Hoeveel RAM? Is het sneller als je je normal.mxt verwijdert/hernoemt? (test de tweede keer nadat het is verwijderd sinds de eerste keer opstarten, het kost tijd om het opnieuw te maken) Hebt u aanpassingen geïnstalleerd?
toegevoegd de auteur saint_groceon, de bron
@mattwilkie De opstarttijd voor ArcMap was vroeger veel langzamer. Om dit te verbeteren introduceerden ze just-in -time-extensies . Ik weet het niet zeker, maar ik denk dat een vergelijkbare benadering wordt gevolgd met gx-objecten die worden geladen wanneer u de eerste keer het dialoogvenster Gegevens toevoegen opent.
toegevoegd de auteur saint_groceon, de bron
Kirk: geweldig antwoord. @mattwilkie: het is waar. Mevrouw Office had op een gegeven moment ongeveer 400 (+?) COM-objecten. Ik denk dat de GeoDatabase inmiddels zoveel heeft. De waarheid is dat ESRI, in voor- en tegenspoed, een beetje COM gek is geworden. Ik denk dat het voor die tijd een veilige, verstandige beslissing was.
toegevoegd de auteur FlySwat, de bron
hmm. Opstarttijd is voor mij niet sneller (als ik ga uit het geheugen, niet uit gegevens, dus het kan gewoon perceptie zijn). 17s van het klikken op knop Arcmap 10 in de taakbalk totdat het gereed is om iets te doen (met de wizard "Last laatste kaart laden" uitgeschakeld). 2e sessie is ongeveer 12s. Dit is na het vervangen van de C: harde schijf door een SSD. Quantum neemt 4s voor de eerste run en 2s voor de volgende.
toegevoegd de auteur Greg, de bron
Een paar jaar geleden vertelde een Esri-verkoper mij dat Esri de grootste COM-bibliotheek ter wereld heeft, die met gemak groter is dan alles wat Microsoft ooit had gebouwd. Ik heb sindsdien aangenomen dat een deel van de traagheid van Arcgis Desktop al die bibliotheken in één keer laadt, in plaats van alleen de stukjes en beetjes te pakken die op verzoek nodig zijn.
toegevoegd de auteur Greg, de bron

ArcGIS lijkt erg opgeblazen. Ik herinner me een enorme prestatiehit bij het migreren van Arcview 3.2 naar ArcGIS 8.0, en op veel plaatsen bestaat het nog steeds. In die tijd dacht ik dat het veel te maken had met het feit dat ESRI eerdere Arc/Info-code naar Windows migreerde en een aantal hoeken in de prestaties moest snijden, maar ik weet niet zeker of dat waar is. Ik herinner me dat ik enkele voorbeelden op deze site zag over functies die nog steeds dramatisch sneller zijn in Arcview 3.3 dan ArcGIS 10. Dit heeft niets te maken met opstarttijden, enz. En ik ben het niet eens met het vorige antwoord dan met gebruikersvaardigheden. '. Het klikken en wachten heeft niets te maken met vaardigheden.

Ik denk dat de realiteit is dat ArcGIS niet is geschreven met het oog op prestaties en elke versie probeert steeds meer functionaliteit op een al overbelast code-platform te gooien.

10
toegevoegd

Vergeef me voor het herleven van de thread, maar ik kan een specifiek voorbeeld geven van hoe de gebruikerservaring verschilt voor ArcMap en QGIS.

Vandaag moest ik een puntenraster bouwen met een onderlinge afstand van 250 meter over een klein land, het puntenraster naar een landrandpolygoon knippen en de waarden van verschillende rasters koppelen aan het puntenraster.

In ArcMap kostte dit me ongeveer 10 minuten, van het downloaden van de gegevens tot een voltooide dataset. In QGIS (Wroclaw) crashte het programma tweemaal door alleen het raster met de polygoon te knippen, waarna het een uur lang rende voordat het bij de derde poging werd voltooid. Dit is op een doos met 4 dual-cores en 6 Gb RAM.

Ik ben dol op QGIS en het stemt mij af om ArcMap te gebruiken, maar ik vind veel algemene gebruikscases waarin QGIS niet aan mijn behoeften voldoet.

Als iemand advies heeft voor het afstemmen van prestaties waarmee deze prestatiekloof kan worden opgelost, ben ik een en al oor.

Chris

7
toegevoegd
Klinkt als een insect voor mij. Crashen is geen maat voor slechte prestaties, maar een symptoom van iets dat fout is. Meld dit aan QGIS-mensen
toegevoegd de auteur Lars Mæhlum, de bron
Voor hoe groot een gebied bouw je dit puntenraster? Liep hetzelfde type bewerking zonder problemen op 57K-punten in QGIS (1.9).
toegevoegd de auteur dpollitt, de bron
afgesproken, maar voor wat het waard is, kom ik altijd eerst naar QGIS en als het daar niet werkt, ga ik terug naar ArcGIS
toegevoegd de auteur Cell-o, de bron
@Simbamangu dit was voor een selectiekader rond Honduras - ongeveer een half miljoen punten. bij Nicklas_Aven: Point taken; als ik tijd heb om betrouwbaar te reproduceren, zal ik indienen.
toegevoegd de auteur Peter Shor, de bron

Dit heeft betrekking op ArcGIS-prestaties: ArcMap, ArcCatalog very traag te openen op een nieuwe laptop met voldoende bronnen? , die mogelijk gedeeltelijk verantwoordelijk zijn voor enkele prestatieproblemen. Die thread laat zien hoe de configuratie van hardware, netwerk en licenties een substantieel effect kan hebben op de ArcGIS-prestaties. Mogelijk kunnen sommige van de vermelde verschillen in snelheid te wijten zijn aan dergelijke factoren in plaats van inherente verschillen in mogelijkheden.

(Gepost als antwoordlink, omdat reacties vaak verloren gaan.)

6
toegevoegd
Antwoorden en opmerkingen hebben hier verschillende doelen, Dan. Je hebt gelijk, reacties hebben een tweederangs status. Eén reden is om echt nuttige antwoorden te benadrukken. Alles wat geen antwoord is, moet een poging zijn om een ​​vraag te beantwoorden of om een ​​vraag of antwoord te verbeteren: dat is een opmerking, zelfs als het echt schitterend is.
toegevoegd de auteur whuber, de bron
Overeengekomen dat de versie in onze labs beter werkt dan de proefversie die ik op mijn pc uitvoer ...
toegevoegd de auteur Cell-o, de bron

Ik denk niet dat Arc is geschreven in .NET. Arcobjecten zijn geschreven in C ++. Arc kan langzamer zijn dankzij veel geavanceerde GUI's, hulpgereedschappen, add-ons enz. QGIS is geweldige software, maar het mist een aantal handige functies die goed kunnen zijn voor beginners. Ook denk ik niet dat basale lavelhulpmiddelen in ESRI (Arcobjects) traag zijn. Het komt meestal neer op gebruikersvaardigheden, als de gebruiker Arc weet te gebruiken, is het helemaal niet zo langzaam. Dat gezegd hebbende, moet ik ook vermelden dat elk hulpmiddel per geval moet worden bekeken met betrekking tot zijn prestaties. Het andere is dat Arc voor het eerst in de GIS-scene was. Ten eerste (in verhouding tot QGIS) zit er altijd een probleem en de volgende generatie is iets beter, in dit geval sneller, maar dit is allemaal mijn persoonlijke mening.

6
toegevoegd
Sidenote: Ik vermoed dat op zijn minst delen van de kern van ArcGIS nog steeds worden geschreven in Fortran (wat volgens geruchten zo snel, zo niet sneller is dan, C voor bepaalde numerieke taken): Als je een .NET console-applicatie uitvoert die gebruikmaakt van ArcObjects en u drukt op Ctrl + C terwijl een ArcObjects een bepaalde bewerking uitvoert, krijgt u een bericht van een Fortran-runtime-bibliotheek.
toegevoegd de auteur Ian Robinson, de bron
@stakx Er zit overhead in die Fortran-code, althans aan de rasterzijde (Spatial Analyst). Ik heb Fortran add-ons ontwikkeld voor SA en heb ontdekt dat ze altijd minstens vijf keer sneller zijn uitgevoerd. Door de jaren heen hebben de lagen wikkels op wikkels op wikkels die zijn gebouwd om de originele (vintage 70's en 80's) code te integreren, de Arc * -prestaties steeds zwaarder belast.
toegevoegd de auteur whuber, de bron
Ook zonder op de nitty gritty details in te gaan, is ArcObjects gebaseerd op COM , een van de vroege interoperabiliteit frameworks, en heeft zijn eigen prestatieverplichtingen, vooral bij het verzamelen tussen beheerde (bijv. .NET) en onbeheerde (C ++) code.
toegevoegd de auteur blah238, de bron

Ik werk met gegevens op ondernemingsniveau (Point of Interest-gegevens voor heel Turkije bijvoorbeeld) en soms alleen om de dataset te controleren, ik heb die weergave nodig.

Als u uw prestaties met ArcGIS wilt verbeteren, zijn er enkele dingen die ik zou kunnen adviseren;

Gebruik altijd geprojecteerde gegevens. Gebruik geodatabases of ArcSDE met postgresql werkt perfect voor mij.

Met behulp van bestandsgeodatabase en zo mogelijk arcsde verhoogt de snelheid van uw bewerkingen. Mijn persoonlijke ervaring met QGIS en ArcMap is eigenlijk het tegenovergestelde. Omdat het bijna minuten kost om 3 miljoen punten op een kaart weer te geven. Aan de andere kant geeft ArcMap ze binnen enkele seconden weer.

Gewoon mijn mening.

2
toegevoegd
Waarom zou je 3 miljoen punten verdienen? Als je bedoelt dat de laag 3 miljoen punten heeft en sommige in jouw ogen, dat is ook snel in QGIS, maar je hebt een ruimtelijke index nodig. Maar ik ben het ermee eens dat QGIS behoorlijk moeilijk kan zijn om te stoppen als je de fout maakt om te veel geometrieën te maken. Zelfs wanneer de weergave met esc wordt vermoord, hangt de reeds gerende geoemtrie daar soms.
toegevoegd de auteur Lars Mæhlum, de bron