89 votes

Problème de débogage lent dans Visual Studio

Dans mon instance Visual Studio, même si je viens d'écrire une seule ligne de retour dans une application console C#, il me faudra une minute après avoir appuyé sur F5 pour exécuter le code réel (je veux dire le temps qu'il faut pour s'arrêter sur l'unique instruction de retour après avoir appuyé sur la touche F5 -- J'ai mis un point d'arrêt sur l'instruction de retour dans les main fonction). Qu'est-ce qui ne va pas ? Existe-t-il une liste de contrôle ?

J'utilise Visual Studio 2008 VSTS edition et je débogue sur Windows Server 2003 x64.

2 votes

Juste pour être sûr... De quelle quantité de mémoire disposez-vous lorsque vous essayez d'exécuter le code ? D'après mon expérience, VS est très gourmand en mémoire...

1 votes

Quel est votre matériel ? Visual Studio est très gourmand en disque et en processeur, donc une machine bon marché ne sera pas aussi performante.

1 votes

Avoir > 2-3 points d'arrêt conditionnels est mal géré par VS...

153voto

zweiterlinde Points 5984

Il se peut que vous deviez supprimer tous vos points d'arrêt - notez que vous devez cliquer sur le bouton "Supprimer tous les points d'arrêt" (ou utiliser le bouton "Supprimer tous les points d'arrêt"). Ctrl + Shift + F9 ), PAS il suffit de les supprimer un par un. Si Visual Studio a modifié les paramètres de votre solution, cette dernière solution ne fonctionnera pas. Il se peut que vous deviez d'abord ajouter un point d'arrêt pour que cela fonctionne (astucieux, non ?).

Si le pire est à craindre, vous devrez peut-être supprimer votre .suo et laisser Visual Studio en créer un nouveau à partir de zéro. Notez toutefois que vous perdrez vos paramètres de configuration personnels de la solution (uniquement pour cette solution, pas pour les autres). Cependant, vous pouvez déplacer/renommer le fichier temporairement jusqu'à ce que vous déterminiez si c'est le problème ou non ; de cette façon, vous pourrez toujours le déplacer à nouveau. J'ai vu certaines ressources en ligne recommander de supprimer (déplacer/renommer) le fichier .ncb également.

2 votes

Salut, zweiterlinde. Je trouve que le goulot d'étranglement devrait concerner le réseau. Lorsque je débranche le câble réseau, les performances sont très bonnes en débogage. Avez-vous une idée de pourquoi ? et comment l'évaluer plus avant ?

0 votes

La suppression d'un fichier .suo de 14Mo a fonctionné pour moi :) il ne fait plus que 150Ko. le problème est survenu après la mise à jour de VS2010 Pro vers Ultimate

0 votes

+1. Merci beaucoup, ça a marché). Mon VS 2010 a mis 2 minutes pour démarrer un projet sur une station de travail. Huh. Quel bug....

26voto

m-sharp Points 4349

J'ai déjà vu cela auparavant. Essayez de supprimer tous vos points d'arrêt, puis définissez ceux que vous voulez. Cliquez sur F5 . Est-il plus rapide maintenant ?

Je viens de remarquer que vous avez mentionné la mise en place de la fonction de débogage des sources .NET. Essayez de la désactiver. Votre connectivité réseau au serveur source de Microsoft peut être lente. Désactivez également toute connectivité au serveur de symboles dans le menu OutilsOptionsDébogageSymboles .

Essayez également de désactiver "Activer l'évaluation des propriétés et autres appels de fonctions implicites" dans le menu OutilsOptionsDébogageGénéral .

1 votes

Dans ma fenêtre de points d'arrêt, il n'y en a qu'un seul sur l'instruction de retour de ma fonction Main. D'autres listes de contrôle ?

1 votes

Ajouté plus de choses à essayer. J'espère que cela vous aidera.

0 votes

J'ai supprimé le seul point d'arrêt sur l'instruction de retour de ma fonction Main, mais le démarrage et l'arrêt de l'application sont toujours très lents, ils prennent environ une minute. Avez-vous d'autres idées ?

20voto

Frank Points 71

Ou supprimez votre fichier .suo qui se trouve à côté de votre fichier de solution (.sln). Cela a résolu un problème que j'avais avec les sessions de débogage qui prenaient beaucoup de temps à démarrer et à s'arrêter.

0 votes

+1 pour avoir sauvé ma santé mentale (et m'avoir évité une réinstallation de VS2010). Merci !

0 votes

C'est également la solution référencée sur MSDN : social.msdn.microsoft.com/Forums/vstudio/en-US/

0 votes

Je confirme que cela s'applique également aux anciennes versions 2003.NET et 2005. Une application avait quelques points d'arrêt et fonctionnait bien. J'ai ajouté quelques points d'arrêt supplémentaires... 100% d'utilisation du CPU et un scintillement terrible dans VS lors du débogage. J'ai fermé VS, supprimé l'application .suo réouvert et le débogage est à nouveau rapide.

6voto

1800 INFORMATION Points 55907

Avez-vous beaucoup de points d'arrêt définis ? Ils peuvent vraiment ralentir le temps de démarrage. Chaque fois qu'un nouveau module est chargé dans l'espace d'adressage du processus, ils doivent tous être vérifiés pour voir s'ils sont valides.

0 votes

Je n'ai qu'un seul point d'arrêt dans mon code en mode utilisateur. Mais je me souviens qu'une semaine auparavant, j'ai utilisé la fonction de débogage de la source dans Visual Studio pour définir des points d'arrêt dans le code interne de .Net. Y a-t-il un moyen de vérifier tous les points d'arrêt, y compris ceux que j'ai définis dans le code interne de .Net ?

0 votes

Aucune, mais toujours lent, d'autres idées ?

0 votes

Pas vraiment, il semble que votre matériel devrait être ok et tous les autres éléments que j'aurais essayé semblent avoir été coché par d'autres commentateurs. A ce stade, j'essaierais probablement de réinstaller Visual Studio - peut-être que quelque chose s'est produit lors de l'installation.

6voto

Steve Steiner Points 4044

Aller au menu OutilsOptionsDébogueurSymboles et vérifiez si vous avez défini des symboles publics ou UNC ensemble de chemins de réseau. Consultez également le menu Outils* → OptionsDébogueurGénéral pour voir si vous avez défini un serveur source.

Tous ces éléments peuvent affecter le débogage en fonction de la lenteur du réseau ou de l'indisponibilité des serveurs. Le temps d'attente de 5 minutes est dû aux délais d'attente du réseau.

Si rien n'est défini dans les options, vérifiez si la variable d'environnement _NT_SYMBOL_PATH est définie.

0 votes

Merci, c'était ça pour moi. Je chargeais occasionnellement 1 ou 2 fichiers de symboles dans la fenêtre Modules, pointant vers des symboles de nos constructions via des chemins UNC, ou moins fréquemment, pointant vers des machines virtuelles qui n'existent plus. Je n'avais pas réalisé qu'il sauvegardait tous ces chemins dans les paramètres de Debugger/Symbols.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X