Visual Studio - Impact d'exécution des points d'arrêt conditionnels et des personnes handicapées

Question

Après avoir passé un peu de temps se demandant pourquoi mon application a été en cours d'exécution d'un scénario particulier très lentement avec le débogueur attaché, j'ai découvert que cela était dû à avoir un point d'arrêt conditionnel (dont l'état n'a jamais été comblés). Cela semble raisonnable, comme le CPU signalerait le point d'arrêt et VS aurait besoin d'évaluer la condition avant d'autoriser l'exécution de continuer. Ces transitions doivent être coûteuses.

Je suppose qu'un point d'arrêt dans un chemin de code qui n'a pas été exécuté n'a pas d'impact d'exécution.

Alors ma question est double:

1. Y a-t-il des ressources qui peuvent quantifier les coûts associés à points d'arrêt conditionnels, et si oui est-ce que l'on peut faire pour réduire leur coût d'évaluation de l'exécution?
2. Est-il un coût associé à un point d'arrêt « handicapé »? Par personnes handicapées Je veux dire que VS affiche le marqueur point d'arrêt dans la gouttière avec un cercle creux.

Bien sûr, si tout ce que je l'ai mentionné ci-dessus n'a pas de sens, alors s'il vous plaît me diriger dans la bonne direction.

Answer 1

Il est difficile de quantifier le coût d'un point d'arrêt conditionnel. L'expression dans un point d'arrêt conditionnel est évaluée en utilisant la même sémantique exacte que si vous l'aviez tapés dans la montre ou la fenêtre immédiate. Les expressions de cette nature ne sont pas réellement exécutées dans le programme client, mais plutôt traitée par l'évaluateur d'expression spécifique de la langue. Il est pas vraiment possible de profiler ces types d'évaluations de manière significative.

Cependant, je peux énumérer quelques petites choses qui sont connus pour être plus lente dans une fenêtre de débogage eval

• Fonction Appels: Ils sont les plus lents chose que vous pouvez faire parce que l'appel de fonction nécessite le processus débogué à être redémarré pour que la fonc eval peut se produire dans le processus
• Comparaison de chaînes: Sous le capot ceux-ci revenir à fonc evals

En ce qui concerne les points d'arrêt handicapés, non, ils ne portent pas atteinte au fonctionnement de l'application.

Answer 2

Une chose à surveiller (que j'ai appris à la dure) est de vous assurer que vous mettez == lorsque l'on compare une variable à une valeur et non le seul =

L'éditeur de points d'arrêt ne vous avertit pas, mais lorsque le point d'arrêt est évaluée, la variable est modifiée! Il m'a fallu un certain temps pour déboguer mon code avec celui-là!

En outre, si je vraiment besoin du point d'arrêt conditionnel au code bebug; Ajouter la condition au code, puis ajouter quelque chose comme chaîne stop = « ici »; et mettre un point d'arrêt il normal - je trouve le code est plus rapide puis

.

Answer 3

Je lis somwhere qu'il ya un support matériel pour ces points d'arrêt, de sorte que l'utilisation de moins de x points d'arrêt conditionnels d'un certain type est essentiellement libre, mais au-dessus de cela, il a besoin d'utiliser plus de logiciels. (OTOH, qui était pour les applications natives, pas sûr de ces choses dernier cri JIT).

handicapés devraient prendre des points d'arrêt affecter les choses du tout, ils ont juste occopy des ressources mémoire et l'interface graphique dans IDE.

Answer 4

Je l'ai aussi remarqué que points d'arrêt conditionnels sont coûteux et est venu à la même conclusion que vous. Je ne peux imaginer aucune raison qu'un point d'arrêt désactivé causerait un ralentissement puisque je pense que ce soit un éditeur seule chose, un raccourci pour activer un point d'arrêt en cas de besoin.

Ce que je fais quand je suis dans une situation comme la vôtre est faire une macro assert. (Vous pouvez utiliser le assert macro qui fournit visual studio, mais je ne l'aime pas). Faites vérifier macro la condition que vous voulez, puis appelez DebugBreak si elle échoue. Dans le realease ou la construction non vérifiés de votre demande, ont rien affirmer d'évaluer, de sorte que votre code n'est pas affecté.

Une simple macro assert peut ressembler à:

#ifdef _DEBUG
#define assert(x)\
do{\
  if(!(x)){DebugBreak();}\
}while(0)
#else
#define assert(x)
#endif

et appelez comme:

assert(pValue != NULL && "A bad parameter was passed to the function");

Vous pouvez mettre plus de code dans l'échec avant DebugBreak (comme l'impression de la condition qui a échoué n ° X, et / ou le numéro de ligne / fichier avec ____FILE____ et ____LINE____ afin que vous pouvez double-cliquer sur le message). Vous pouvez écrire des messages dans le journal de débogage avec OutputDebugString et même vérifier si un débogueur est attaché avec IsDebuggerPresent pour adapter vos assert encore plus. J'aime aussi utiliser le && format de chaîne pour donner un peu plus d'informations sur le assert particulier.

Il y a quelques petites choses à faire attention lors de l'utilisation assert. Tout d'abord, ne mettez pas le code qui doit être exécuté dans la macro, car il sera dépouillé dans une version de débogage non. Pour les mêmes raisons, ne pas mettre dans le code qui a des effets secondaires. En outre, vous ne voulez pas appeler DebugBreak () lorsqu'un débogueur est pas attaché, car il jette essentiellement une exception, qui sinon pris, mettra fin à l'application.

Answer 5

1. Essayez de mettre le point d'arrêt dans votre code pour tester les performances. Par exemple.

   Stopwatch st = new Stopwatch();
   st.Start();
   if(my condition)
   {
     st.Stop();
     Debugger.Break();
   }
   

   Non, pas exactement la même chose, mais assez proche.

2. Non - un point d'arrêt désactivé n'est pas présent dans le programme d'exécution. Il est tout simplement stockée dans les métadonnées VS pour votre commodité.