Pourquoi la vitesse des performances entre ArcGIS et QGIS est-elle si différente?

Ok je ne suis pas un programmeur mais un utilisateur SIG prolifique. Je sais que QGIS est écrit en C ++ et ArcGIS en ??? mais pour la plupart de mes tâches ces derniers temps, j'essaie toujours d'utiliser QGIS non seulement parce qu'il est gratuit mais aussi parce que son expérience utilisateur est si bonne.

Tous les gourous du SIG, pouvez-vous me dire quelques raisons de la différence de vitesse entre ces deux systèmes? Honnêtement, cela me fait mal d'utiliser ArcGIS 10 en raison de sa vitesse et j'ai un PC avec 8 Go de RAM.

ArcGIS semble très gonflé. Je me souviens d'un énorme impact sur les performances lors de la migration d'Arcview 3.2 vers ArcGIS 8.0, et dans de nombreux endroits, il existe toujours. À ce moment-là, je pensais que cela avait beaucoup à voir avec la migration d'ESRI du code Arc / Info précédent vers Windows et de devoir réduire certains coins dans les performances, mais je ne suis pas sûr que ce soit vrai. Je me souviens avoir vu sur ce site des exemples de fonctions qui sont encore beaucoup plus rapides dans Arcview 3.3 qu'ArcGIS 10. Cela n'a rien à voir avec les temps de démarrage, etc. Et je ne suis pas d'accord avec la réponse précédente qu'avec les compétences utilisateur '. Cliquer et attendre n'a rien à voir avec l'habileté.

Je pense que la réalité est qu'ArcGIS n'a pas été écrit en pensant aux performances et que chaque version continue d'essayer de lancer de plus en plus de fonctionnalités sur une plateforme de code déjà surchargée.

Je ne connais pas très bien QGIS, mais je me demande comment il se compare à ArcGIS en termes d'extensibilité. Malheureusement, il semble y avoir au moins quelques compromis entre l'extensibilité et les performances. La meilleure façon que j'ai trouvée pour avoir une idée de l'extensibilité d'ArcGIS est de jeter un œil aux catégories de composants COM d'Esri trouvées dans le registre.

Chaque catégorie représente un endroit où les utilisateurs peuvent enregistrer des dll contenant des classes qui implémentent une interface Esri. Il y a beaucoup de catégories. Ces catégories contiennent également des aliments pour chiens - Esri les utilise non seulement pour découvrir des personnalisations tierces, mais également des fonctionnalités prêtes à l'emploi. Bien que cela offre un niveau de personnalisation très fin, cela signifie également que tous ces grains fins doivent être découverts et chargés au moment de l'exécution. Je ne sais pas quel est le coût de la réinstallation , mais il doit être important.

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

Lorsque vous créez une DLL dans Visual Studio, il existe un endroit où vous pouvez spécifier l'adresse de base pour la DLL à charger. Comme il y a tellement de DLL de tailles différentes en cours de chargement, il sera très difficile de le savoir à l'avance pour une personnalisation d'ArcObjects. Pourtant, je me demande si un fichier de configuration pourrait être créé indiquant où la DLL doit être chargée en mémoire. Si c'est le cas, une fois qu'un utilisateur a exécuté arcmap avec les DLL chargées qu'il utilisera généralement, il pourrait exécuter une routine qui écrirait les adresses de base des DLL dans un fichier de configuration. De cette façon, lorsque arcmap démarre, il pourrait éviter la relocalisation en chargeant dans ces adresses. Là encore, peut-être qu'avec 64 bits, cela n'aura pas d'importance.

À 10,0, Esri a introduit des compléments. Les catégories de compléments sont beaucoup plus petites et la découverte ne dépend pas du registre Windows. Au lieu de cela, les DLL du complément sont zippées et placées dans un dossier connu. Je ne sais pas comment cela se compare aux performances avec les DLL découvertes via le registre Windows. Je pense que l'objectif principal était de permettre l'installation par des non-administrateurs.

Je suppose que la question fait référence au produit Desktop. Le nouveau produit ArcGIS Runtime est beaucoup plus léger. Je l'ai entendu décrit comme un remplacement de MapObjects. Il sera intéressant de voir comment il évolue. Si Esri introduit une extensibilité pour WPF Runtime, j'espère qu'ils n'utilisent pas le même mécanisme de découverte utilisé par Visual Studio lorsqu'il remplit la liste des assemblys. Cette première fois, cliquer sur "Ajouter une référence ..." est devenu extrêmement lent.

Pardonnez-moi d'avoir ressuscité le fil, mais je peux donner un exemple spécifique de la façon dont l'expérience utilisateur diffère pour ArcMap et QGIS.

Aujourd'hui, je devais construire une grille de points avec un espacement de 250 mètres à travers un petit pays, couper la grille de points à un polygone de frontière de pays et associer les valeurs de plusieurs rasters à la grille de points.

Dans ArcMap, cela m'a pris environ 10 minutes, du téléchargement des données vers un ensemble de données terminé. Dans QGIS (Wroclaw), le programme s'est écrasé deux fois juste en découpant la grille avec le polygone, puis a fonctionné pendant une heure avant de terminer la troisième tentative. C'est sur une boîte avec 4 dual-cores et 6 Go de RAM.

J'adore QGIS et cela me contrarie d'utiliser ArcMap, mais je trouve de nombreux cas d'utilisation courants où QGIS ne répond pas à mes besoins.

Maintenant, si quelqu'un a des conseils de réglage des performances qui pourraient résoudre cet écart de performances, je suis tout à fait à l'écoute.

Chris

Je ne pense pas que Arc soit écrit en .NET. Les Arcobjects sont écrits en C ++. L'arc peut être plus lent en raison de l'utilisation de nombreuses interfaces graphiques avancées, outils d'aide, modules complémentaires, etc. QGIS est un excellent logiciel, mais il manque certaines fonctionnalités utiles qui peuvent être bonnes pour les débutants. Je ne pense pas non plus que les outils de base de lavel dans ESRI (Arcobjects) soient lents. Cela se résume généralement aux compétences des utilisateurs, si les utilisateurs savent comment utiliser Arc, ce n'est pas si lent du tout. Cela dit, je dois également mentionner que chaque outil doit être examiné au cas par cas en ce qui concerne ses performances. L'autre chose est que, Arc était le premier sur la scène SIG. La première (relativement à QGIS) est toujours avec des bugs et la prochaine génération est un peu meilleure, dans ce cas plus rapide, mais tout cela n'est que mon opinion personnelle.

Cela concerne les performances d'ArcGIS: ArcMap, ArcCatalog très lent à ouvrir sur un nouvel ordinateur portable avec de nombreuses ressources? qui peut en partie expliquer certains des problèmes de performance. Ce thread montre comment le matériel, le réseau et la configuration des licences peuvent avoir un effet substantiel sur les performances d'ArcGIS. Il est possible que certaines des différences de vitesse signalées soient dues à de tels facteurs plutôt qu'à des différences inhérentes de capacités.

(Publié comme lien de réponse, car les commentaires ont tendance à se perdre.)

Je travaille avec des données au niveau de l'entreprise (données de points d'intérêt pour toute la Turquie par exemple) et parfois juste pour vérifier l'ensemble de données, j'ai besoin de ce rendu.

Si vous souhaitez améliorer vos performances avec ArcGIS, il y a peu de choses que je pourrais conseiller;

Utilisez toujours les données projetées. Utilisez des géodatabases ou ArcSDE avec des travaux postgresql parfaits pour moi.

Utiliser la géodatabase fichier et si possible arcsde augmente la vitesse de vos opérations. Mon expérience personnelle avec QGIS et ArcMap est en fait le contraire. Comme cela prend presque quelques minutes pour rendre 3 millions de points sur une carte. D'un autre côté, ArcMap les rend en quelques secondes.

Juste mon avis.