Visual Studio application en cours d'exécution très lente avec debug
J'ai un natif programme en C++ qui gère plus de 20 fois plus lent lorsqu'il est démarré avec Debug (F5), mais fonctionne à vitesse normale lors de l'utilisation de démarrer sans debug (Ctrl + F5).
Il n'est pas question que j'utilise un debug ou release construire. Aussi, si j'utilise WinDbg le programme est d'une magnitude plus lent.
Est-il un paramètre que je ne choisissez mauvais ou quelque chose?
- Debug ajoute beaucoup de frais généraux à un programme. Pourquoi êtes-vous en supposant que les choses sont mal?
- Debug ne devrait pas ajouter beaucoup de frais généraux. La différence entre un débogueur et pas de joint ne doit pas être une différence.
Vous devez vous connecter pour publier un commentaire.
Définir la _NO_DEBUG_HEAP variable d'environnement à 1 (comme on le voit sur http://preshing.com/20110717/the-windows-heap-is-slow-when-launched-from-the-debugger).
Cela peut être fait à partir de l'intérieur de Visual Studio, trop.
Maintenant, c'est juste une solution de contournement, et je suis curieux de savoir comment refactoriser un programme qui souffre de ce genre de problème. Vous disposez de nombreux std::map, shared_ptr, ou toute autre grande indirections, par hasard?
Ce n'est évidemment pas dû au _DEBUG symbole défini ou de compiler le code dans la configuration de débogage. L'ajout de débogage de code s'exécute si oui ou non le débogueur est attaché au programme.
Le débogueur n'a normalement pas d'incidence sur l'exécution de code, il reste en dehors de la voie en appelant WaitForDebugEvent. Ce qui bloque, jusqu'à ce que le système d'exploitation qu'il indique que quelque chose de remarquable qui s'est passé. Que peut déclencher un tas de code dans le débogueur qui peuvent ralentir votre programme. Vous pouvez voir les événements répertoriés dans la DEBUG_EVENT structure de la documentation.
Annoter un peu au-delà de la documentation: le débogueur étapes et peut ralentir votre programme lorsque:
Le programme charge ou décharge une DLL. Beaucoup de choses qui se passe au cours de la charge, le débogueur va à la chasse pour un des symboles de débogage du fichier (.apb). Il peut communiquer avec un serveur de symbole de le télécharger. Tous les points d'arrêt qui ont été définies dans le code source de la DLL aurez activé. Cela peut être très lent, mais l'effet est temporaire et généralement seulement ralentit le démarrage. Vous pouvez voir le chargement/déchargement de notification dans la fenêtre de Sortie.
Le programme soulève une exception. Cette commande permet d'activer le débogueur au moment où l'exception est soulevée, une "première chance de notification". Qui peut être très utile, vous pouvez utiliser le Débogage + Exception, Jeté case à cocher pour faire le débogueur s'arrêter lorsque l'exception est levée. Vous pouvez voir le message de notification dans la fenêtre de Sortie. Cette ne ralentir code qui lève et attrape les exceptions énormément et il est très probable que la source de votre ralentissement. Ne jamais utiliser les exceptions pour le contrôle de flux.
Un thread démarre ou s'arrête. De nouveau, un message de notification est imprimé à la fenêtre de Sortie. Vous devez créer un beaucoup de threads pour faire de ce ralentir votre programme.
Lorsque votre programme utilise OutputDebugString() à des fins de traçabilité. Visible dans la fenêtre de Sortie. Un autre bon candidat pour un ralentissement, des chutes de la production dans le seau bits si aucun débogueur est attaché. Vous ne devriez pas avoir de la difficulté à diagnostiquer ce que la cause, l'évidence d'effets secondaires est de voir un beaucoup de messages dans la fenêtre de Sortie.
Lorsque le programme rencontre un point d'arrêt. Pas beaucoup de raisons d'être perplexe par celui-là. Mais vous pouvez définir des points d'arrêt qui ralentissent le programme beaucoup encore ne pas provoquer un saut de débogueur. En particulier, le point d'arrêt Conditionnel, compteur, Filtre et le moment de Frapper le fonctionnement sera lente. Utiliser Debug + Windows + des points d'arrêt pour examiner les points d'arrêt définis.
Lorsqu'un processus est créé sous le débogueur, le système d'exploitation par défaut utilise le débogage tas. Le débogage tas n'est plus de la vérification de votre mémoire, en particulier à de-alloc.
Il y a plusieurs options possibles en vue de désactiver l'utilisation du Debug Tas:
Il y a plusieurs choses qui sont différentes si vous exécutez la version de débogage à l'extérieur de l'IDE. L'une est que l'IDE prend un certain temps à charger les symboles, et si l'on dépend de beaucoup de bibliothèques alors que le temps de démarrage peut être importante.
Si vous utilisez un serveur de symbole (y compris les publics de Microsoft serveur de symbole), alors ce peut ajouter le temps de démarrage, afin de vous assurer d'avoir un symbole local cache dans votre
_NT_SYMBOL_PATHvariable si c'est le cas.Aussi l'IDE s'exécute avec le debug tas activé, mais je ne pense pas que cela se produit si vous exécutez l'extérieur de l'IDE.
Pour moi la différence de performance entre le mode debug et release mode est d'environ un facteur 40. Après quelques recherches, il semblerait que plusieurs choses contribuent à la différence dans la performance, mais il y a une option du compilateur que quadruple mon debug performance presque gratuit.
À savoir, la modification de
/ZIen/Zi. Pour une description, voir la page MSDN.Je n'utilise pas le modifier et continuer caractéristique de toute façon.
De débogage de Visual C++ vient avec beaucoup, beaucoup de frais généraux, en particulier dans la STL. Essayez de ne pas définir
_DEBUG, et de définirNDEBUG.Personne n'a mentionné la fermeture de source non windows.
Après la fermeture de 20+ inutilisés windows, débogage source stepping est passé de ~5s retour vers ~.2s. Cette anormalement lent projet de charger une DLL dynamiquement et que DLL est également en train d'être renforcée à travers (et dont la source fenêtres ouvertes) il semble donc probablement liés. C'était pourtant C# (titre et les balises sont non-spécifiques).