Pourquoi mon code n'utilise pas les cycles de processeur disponibles?

Question

J'ai écrit un plugin pour ESRI ArcEditor qui effectue des contrôles de validation sur un réseau routier. Pour vérifier si les règles sont toutes satisfaites, il fait tout un tas d'intersections différentes, avec un tampon et des enveloppes etc. sur les fonctionnalités sélectionnées.

Il a été écrit en C#. Maintenant, ce que je remarque est que cela prend beaucoup de temps pour exécuter les algorithmes donnés sur les fonctionnalités sélectionnées. J'ai chargé le profileur ANTS et optimisé les goulots d'étranglement jusqu'à ce que je ne puisse plus rien faire d'autre.

Une chose étrange que j'ai remarquée est que ANTS a signalé pratiquement aucune utilisation de processeur dans la chronologie - une ligne plate. J'ai ensuite vérifié que le processeur reste inférieur à environ 10% à 15% en utilisant le Gestionnaire des tâches pendant l'exécution de l'opération de validation. Cela n'a aucun sens pour moi. Pourquoi n'utilise-t-il pas les cycles de processeur disponibles?

Il n'y a pas d'E/S en cours car il charge tout depuis ArcSDE. J'ai également vérifié qu'il n'y a pas de trafic réseau appréciable pendant le processus de validation, pensant qu'il attendait peut-être des communications entre ArcEditor et le serveur. J'ai ensuite vérifié les processeurs sur le serveur juste pour m'assurer qu'aucun traitement ne lui était délégué, mais l'utilisation de l'UC est restée stable sur 1% pendant le processus de validation. Je pensais alors qu'ArcEditor supprimait peut-être la priorité dans laquelle les plugins peuvent fonctionner, ou quelque chose de fou comme ça. J'ai donc branché une opération mathématique qui aurait permis de sortir le CPU de 10 secondes maximum, au lieu de la routine de validation, et c'est ce que j'ai fait. L'utilisation du processeur était stable à un peu plus de 50%, ce qui est logique car l'opération de maths aurait un maximum de l'un des noyaux de mon Core 2 Duo. Donc pas de chance là-bas. Et il y a plus de 1 Go de RAM disponible.

Enfin, j'ai essayé de trouver le problème avec perfmon, mais je n'ai pas eu de chance là-bas. Je n'ai pas beaucoup d'expérience avec ça, mais je ne trouve rien de mal.

Est-ce dû à l'interface ArcObjects COM? Bien que j'ai également vérifié les compteurs .NET Interop avec perfmon.

Je suis à perte.

Donc toute aide ou conseils serait grandement appréciée.

Answer 1

Cela peut être un problème de thread. COM lancera automatiquement les appels de méthode sur une interface COM vers le thread approprié. Ce qui est généralement le fil de l'interface utilisateur du programme. Ceci est très lent car il nécessite un commutateur de contexte de thread et le thread d'interface utilisateur doit être dans un état pour répartir l'appel. Peu de cycles de CPU sont brûlés, tout bloque jusqu'à ce que l'appel soit terminé.

Utilisez l'objet COM sur le même thread que celui créé. Ce qui devrait être le thread UI si cet objet a des exigences STA. Ils le font habituellement.