Visual Studio ralentissant l'application

Question

C'est une question un peu vague, mais y a-t-il quelque chose que je peux faire à propos de Visual Studio ralentissant une application? Si j'exécute les exécutables en dehors de Visual Studio, il fonctionne à une vitesse très acceptable. Si je l'exécute dans Visual Studio avec le débogueur activé, il tourne presque 200 fois plus lentement. J'ai essayé de désinstaller et de réinstaller le studio visuel en vain. J'ai enlevé tous mes plugins (fourmis & resharper) et toujours rien. J'ai couru le projet dans un studio visuel sur un autre ordinateur et la vitesse était normale. Que puis-je faire pour résoudre cela? Cela semble s'être passé récemment, mais potentiellement graduellement.

Mise à jour: Je l'ai couru maintenant dans d'autres studios visuels, et le ralentissement maintient. Ma seule conclusion est la façon dont Im allouer de la mémoire dans les vitesses que je suis dans l'application provoque le débogueur à ralentir les choses d'une manière ou d'une autre. Quelqu'un a déjà une expérience dans ce domaine?

Answer 1

En général, le débogueur Visual Studio ne ralentit pas les choses. Cela doit être quelque chose de spécifique à votre application. Par exemple, il y a une question récente sur SO de la part de quelqu'un qui reçoit une exception OutOfMemoryException lors du débogage mais pas lors d'une exécution en dehors du débogueur. Il semble que cela soit dû à la manière dont il alloue la mémoire - la technique est sensible au nombre d'assemblys chargés en mémoire. La plupart des programmes ne seraient pas sensibles à cet effet passif du débogueur. Peut-être que vous souffrez également d'un effet lié au débogueur, mais pas complètement la "faute" du débogueur.

---

Mitch Blé a suggéré que vous utilisez un scanner de virus. Cela m'a rappelé un logiciel similaire qui a pris en charge les assemblages de chargement et de déchargement de Visual Studio. C'était un morceau de logiciel de VPN qui a fourni «la sécurité de point final». Il était destiné à vérifier quels programmes vous étiez en cours d'exécution lors de la connexion au VPN et à vous assurer qu'ils respectaient la politique de sécurité. Cela signifiait être informé de chaque assemblage chargé. Visual Studio charge et décharge un grand nombre d'assemblages. Ce logiciel VPN était tellement intéressé par le fait qu'il a causé un BSOD - la seule fois où j'ai vu une application provoquer un BSOD - parce qu'il installait un filtre de système de fichiers ou autre, et était notifié en mode Kernel. Cela plus un bug de quelque sorte était suffisant pour faire tomber le système.

Donc, en général, cherchez un logiciel qui se soucie de ce qui fonctionne sur votre ordinateur. Peut-être "sécurité des terminaux", peut-être un scanner de virus, peut-être un indexeur de recherche, ou autre chose.

Answer 2

Dessinez-vous des symboles d'un serveur de symboles? C'est une cause fréquente de ralentissement.

Vérifiez _NT_SYMBOL_PATH si elle est définie, ou vos options de débogage si vous utilisez VS 2008 +

Answer 3

Les exceptions sont très coûteux lors de l'exécution dans le débogueur et peut ralentir l'application si beaucoup sont jetés et pris. Jetez un oeil à la fenêtre de sortie de Visual Studio où vous pouvez voir les exceptions levées.

Answer 4

Le débogueur VS ajoute à votre code des commandes supplémentaires afin de permettre toutes les fonctionnalités qu'il apporte. L'inconvénient peut ralentir votre application. C'est peut-être la raison pour laquelle votre application fonctionne correctement lorsque vous exécutez l'exécutable sur un autre ordinateur.

Ensuite, c'est un problème qui ne devrait pas vous déranger, car la version de l'application est importante - qui se soucie des performances de la version de débogage si la version finale fonctionne bien.

Answer 5

Le problème est que Windows tombe dans un segment de débogage spécial, s'il détecte que votre programme s'exécute sous un débogueur. Cela semble se produire au niveau du système d'exploitation et est indépendant de tous les paramètres du mode Déboguer/Libérer pour votre compilation.

Vous pouvez contourner cette « fonction » en définissant une variable d'environnement: _NO_DEBUG_HEAP = 1

Cette même question me conduire a été noix pendant un certain temps; Aujourd'hui, j'ai trouvé ce qui suit, d'où ce poste est dérivé: http://blogs.msdn.com/b/larryosterman/archive/2008/09/03/anatomy-of-a-heisenbug.aspx