ArcObjects fonctionnant dans Addin plus lentement?


9

J'ai créé une bibliothèque de classes qui fait du géotraitement. L'addin appelle une classe qui est un processus asynchrone. Je me suis assuré que le thread est STA et que les arcobjects sont thread-safe (c'est-à-dire non transmis depuis l'addin). Tous les arcobjects sont créés dans le fil.

Parce que c'est une bibliothèque de classes, je l'ai enveloppée dans une interface utilisateur winforms et également en tant que complément. Les deux ensembles de codes sont exactement les mêmes et les tests ont été effectués en utilisant exactement les mêmes données. Les winforms et le complément complètent le code avec les résultats souhaités et aucune fuite de mémoire n'est évidente. Pour le cas de l'addin, il n'y a pas d'interaction avec la période de carte à ce stade et il n'y a pas non plus d'éléments de mappage ou d'affichage dans le code winforms.

les seules mises à jour de l'interface utilisateur sont la mise à jour d'une boîte de dialogue de progression dans le complément et l'interface utilisateur. L'addin utilise une fenêtre ancrable (contrôle utilisateur ui).

Le problème que je vois est lorsque la bibliothèque est appelée à partir du complément, l'exécution du code est 5 fois plus lente que le même code appelé via l'application winforms.

Des idées sur où je pourrais chercher pour voir pourquoi cela se produit?


Utilisez-vous des singletons arcobjects ?
Kirk Kuykendall

Oui, jetez un coup d'œil à la liste et j'utilise quelques objets workspacefactory pour ouvrir mes classes de fonctionnalités indépendamment d'ArcMap afin qu'elles soient créées dans le thread. Je crée deux usines d'espace de travail (pour mes entrées et sorties), puis je boucle et met en cache les données localement à l'aide d'un espace de travail inmemmory que j'utilise pour créer une usine. Dois-je créer la fabrique inmemoryworkspace une seule fois? Je dois mentionner que le code n'échoue pas et qu'il est lent uniquement lorsqu'il est exécuté dans le complément.
Justin Carasick

Créez-vous avec Activator.CreateInstanceou avec new?
Kirk Kuykendall

J'utilise (ou utilisais) la nouvelle version. Je mets à jour maintenant pour essayer la méthode Activator.CreateInstance.
Justin Carasick

J'ai mis à jour le code (merci de l'avoir signalé) mais je ne vois pas de réelle différence avec la mise à jour.
Justin Carasick

Réponses:


1

Lorsque vous comparez les deux versions, il se peut que vous programmiez plus que le temps de géotraitement.

Il existe peut-être des procédures d'initialisation en cours d'exécution dans votre application autonome qui sont déjà effectuées dans ArcMap au démarrage, par exemple la création d'un objet MxDocument, le retrait de la licence, la création de GDB scratch, etc.

Il pourrait également y avoir une différence entre la version de .NET Framework utilisée dans ArcMap et votre application de bureau (même si je ne vois pas cela provoquer un ralentissement 5x).

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.