Quel est le véritable surcharge de try/catch en C#?

Je ne suis pas un expert dans les implémentations de langue (afin de prendre cela avec un grain de sel), mais je pense que l'un des coûts les plus importants est le dénouement de la pile et de les stocker pour la trace de la pile. Je soupçonne que cela se produit uniquement lorsque l'exception est levée (mais je ne sais pas), et si oui, ce serait décemment taille de frais cachés, chaque fois qu'une exception est levée... donc ce n'est pas comme vous êtes juste de sauter d'un endroit dans le code à l'autre, il se passe beaucoup de choses.

Je ne pense pas que c'est un problème tant que vous êtes en utilisant les exceptions EXCEPTIONNELLES comportement (donc pas votre typique, de la trajectoire prévue par le programme).

Êtes-vous demander à propos de la surcharge de l'utilisation de try/catch/finally, lorsque les exceptions ne sont pas jetés, ou les frais généraux de l'utilisation des exceptions aux processus de contrôle de flux? Ce dernier est quelque peu semblable à l'aide d'un bâton de dynamite à la lumière d'un tout-petit de l'anniversaire de la bougie, et les frais généraux associés tombe dans les domaines suivants:

• Vous pouvez s'attendre à d'autres défauts de cache en raison de la levée d'une exception accéder aux données qui résident normalement pas dans le cache.

• Vous pouvez s'attendre à d'autres défauts de page en raison de la levée d'une exception accéder à des non-résidents de code et de données qui ne sont pas normalement dans votre application de jeu de travail.

  • par exemple, en jetant l'exception exigera le CLR pour trouver l'emplacement de la enfin et blocs catch basée sur la propriété intellectuelle et le retour IP de chaque image jusqu'à ce que l'exception est traitée plus le bloc de filtre.
  • supplémentaire des coûts de construction et de résolution de nom, afin de créer les images à des fins de diagnostic, y compris la lecture de métadonnées etc.

  • les deux éléments ci-dessus, généralement de l'accès "à froid", le code et les données, donc dur de défauts de page sont probables si vous avez de la mémoire de la pression à tous:

    • le CLR essaie de mettre de code et de données qui est utilisée que rarement loin de données qui est fréquemment utilisé pour améliorer la localisation, de sorte que cela joue contre vous parce que vous êtes forçant le froid à chaud.
    • le coût de la dur de défauts de page, le cas échéant, nain tout le reste.
• Typique attraper les situations sont souvent profond, donc les effets ci-dessus ont tendance à être amplifié (augmentation de la probabilité de défauts de page).

Comme pour l'impact réel du coût, cela peut varier beaucoup en fonction de ce qui se passe dans votre code à la fois. Jon Skeet a un bon résumé ici, avec quelques liens utiles. J'ai tendance à être d'accord avec son affirmation que si vous arrivez à un point où les exceptions sont considérablement nuire à votre performance, vous avez des problèmes en termes de votre utilisation des exceptions au-delà de la performance.

Pour ne pas mentionner si c'est à l'intérieur de l'un des plus fréquemment cette méthode, il peut affecter le comportement global de l'application.

Par exemple, je considère que l'utilisation de Int32.Analyser comme une mauvaise pratique dans la plupart des cas, car il lève des exceptions pour quelque chose qui peut être pris facilement autrement.

Donc pour conclure que tout ce qui est écrit ici:

1) Utiliser try..catch à la capture des erreurs inattendues presque pas de perte de performances.

2) Ne pas utiliser les exceptions pour l'exception des erreurs, si vous pouvez l'éviter.

Contrairement aux théories communément admises, try/catch peut avoir d'importantes implications sur les performances, et que si une exception est levée ou pas!

1. Il désactive automatique des optimisations (par conception), et dans certains cas injecte de débogage code, comme vous pouvez vous attendre à partir d'un débogage aide. Il y aura toujours des gens qui sont en désaccord avec moi sur ce point, mais la langue exige, et le démontage de la montre et qui sont donc par définition dans le dictionnaire délirant.
2. Il peut avoir des effets négatifs sur l'entretien. C'est en fait la question la plus importante ici, mais depuis ma dernière réponse (qui a porté presque entièrement sur lui) a été supprimé, je vais essayer de mettre l'accent sur le problème moins important (la micro-optimisation), par opposition à la plus importante question (la macro-optimisation).

---

L'ancien a été couverte en quelques posts par Microsoft Mvp au fil des années, et j'espère que tu les trouveras facilement encore StackOverflow soucis tellement sur contenu je vais donc donner des liens vers certains de de remplissage la preuve:

• implications sur les Performances de essayer/catch/enfin (et la partie deux), par Pierre Ritchie explore les optimisations qui try/catch/finally désactive (et je vais aller plus loin dans ce avec des citations de la norme)
• le Profilage des Performances Parse au lieu de TryParse au lieu de ConvertTo par Ian Huff états ouvertement que "la gestion des exceptions est très lent" et illustre ce point par les piqûres Int.Parse et Int.TryParse les uns contre les autres... À toute personne qui insiste sur le fait que TryParse utilise try/catch derrière les scènes, ce qui devrait faire la lumière!

Il y a aussi cette réponse qui montre la différence entre un code désassemblé avec et sans l'aide de try/catch.

Il semble donc évident qu'il n'y est une surcharge qui est manifestement observables dans la génération de code, et que les frais généraux semble même être reconnu par des gens qui Microsoft de la valeur! Pourtant, je suis, répéter l'internet...

Oui, il y a des dizaines de extra MSIL instructions pour un trivial ligne de code, et qui ne couvre même pas les handicapés optimisations donc, techniquement, c'est un micro-optimisation.

---

J'ai posté une réponse d'années qui a été supprimé car il était axé sur la productivité des programmeurs (les macro-optimisation).

C'est malheureux, car pas de sauvegarde de quelques nanosecondes, ici et là, de temps CPU est probablement pour beaucoup d'heures cumulées de manuel d'optimisation par l'homme. Qui est-ce que votre patron à payer plus pour: une heure de votre temps, ou d'une heure avec l'ordinateur en cours d'exécution? À quel point nous tirez sur la fiche et admettre que c'est le temps de acheter un ordinateur plus rapide?

Clairement, nous devrions être l'optimisation de nos priorités, et pas seulement de notre code! Dans ma dernière réponse, j'ai dessiné sur les différences entre les deux extraits de code.

À l'aide de try/catch:

int x;
try {
    x = int.Parse("1234");
}
catch {
    return;
}
//some more code here...

Pas à l'aide de try/catch:

int x;
if (int.TryParse("1234", out x) == false) {
    return;
}
//some more code here

Considérer du point de vue d'un entretien développeur, qui est le plus susceptible de perdre votre temps, si ce n'est dans profilage/optimisation (couverts ci-dessus), qui probablement ne serait pas nécessaire s'il n'y avait pas la try/catch problème, puis en faisant défiler le code source... Un de ces quatre lignes supplémentaires de passe-partout de des ordures!

Comme de plus en plus les champs sont introduits dans une classe, tous ce passe-partout ordures s'accumule (à la fois dans la source et du code désassemblé) bien au-delà des niveaux raisonnables. Quatre lignes supplémentaires par domaine, et ils sont toujours les mêmes lignes... n'Étions-nous pas appris à éviter de nous répéter? Je suppose que nous pourrions cacher la try/catch derrière certains brassée maison de l'abstraction, mais... alors nous pourrions aussi bien d'éviter les exceptions (c'est à dire utiliser Int.TryParse).

Ce n'est même pas un exemple complexe; j'ai vu des tentatives de l'instanciation de nouvelles classes dans try/catch. Considérer que l'ensemble du code à l'intérieur du constructeur pourrait alors être disqualifié de certaines optimisations qui seraient autrement appliqués automatiquement par le compilateur. Quoi de mieux pour donner naissance à la théorie que le compilateur est lent, par opposition à le compilateur est en train de faire exactement ce qu'il dit de faire?

En supposant une exception est levée par le constructeur, et certains bug est déclenchée en conséquence, le mauvais entretien de développeur puis a suivre. Qui pourrait ne pas être une tâche facile, car contrairement à l'spaghetti code de la goto cauchemar, try/catch peuvent causer des dégâts dans trois dimensions, comme il pourrait se déplacer vers le haut de la pile non seulement d'autres parties de la même méthode, mais aussi d'autres classes et méthodes, tout ce qui sera observé par le maintien de développeur, à la dure! Pourtant on nous dit que "goto est dangereux", heh!

À la fin je le mentionne, try/catch a ses avantages, il est conçu pour désactiver les optimisations! C'est, si vous voulez, un débogage aide! C'est ce qu'il a été conçu et c'est ce qu'il devrait être utilisé comme...

Je suppose que c'est un point positif aussi. Il peut être utilisé pour désactiver les optimisations qui, autrement, pourrait paralyser sécuritaire, sain de la transmission de message algorithmes pour les applications multithread, et pour attraper possible des conditions de course 😉 C'est sur le seul scénario que je peux penser à utiliser try/catch. Même qui a des alternatives.

---

Ce optimisations ne try, catch et finally désactiver?

A. K. Un

Comment sont try, catch et finally utile que le débogage sida?

ils sont en écriture obstacles. Cela vient de la norme:

12.3.3.13 Try-catch états

Pour une déclaration stmt de la forme:

try try-block
catch ( ... ) catch-block-1
... 
catch ( ... ) catch-block-n

• L'affectation définitive de l'état de v au début de essayez-bloc est le même que l'affectation définitive de l'état de v au début de stmt.
• L'affectation définitive de l'état de v au début de catch-block-je (pour tout je) est le même que l'affectation définitive de l'état de v au début de stmt.
• L'affectation définitive de l'état de v à la fin de stmt est certainement affectée si (et seulement si) v est définitivement attribué à la fin de essayez-bloc et tous les catch-block-je (pour chaque je de 1 à n).

En d'autres termes, au début de chaque try déclaration:

• toutes les assignations faites à des objets visibles avant d'entrer dans le try déclaration doit être complète, ce qui nécessite un fil de verrouillage pour un début, ce qui est utile pour le débogage des conditions de course!
• le compilateur n'est pas autorisé à:
  • éliminer inutilisés affectations de variables qui ont certainement été attribué à l'avant de la try déclaration
  • réorganiser ou de fusionner l'un de ses intérieure-affectations (c'est à dire voir mon premier lien, si vous ne l'avez pas déjà fait).
  • palan affectations au cours de cette barrière, afin de retarder l'affectation à une variable qu'il sait ne pas être utilisé jusqu'à ce que plus tard (le cas échéant) ou de manière préventive se déplacer plus tard attributions de l'avant pour en faire d'autres optimisations possibles...

Une histoire similaire vaut pour chaque catch déclaration; supposons que dans votre try instruction (ou un constructeur ou de la fonction qu'il invoque, etc) que vous attribuez à qui, autrement, inutile variable (disons, garbage=42;), le compilateur ne peut pas éliminer cette déclaration, peu importe comment pas pertinent c'est le comportement observable du programme. La cession doit avoir terminé avant la catch bloc est entré.

Pour ce que ça vaut, finally raconte une de la même façon dégradant histoire:

12.3.3.14 Essayez-enfin états

Pour un essayer déclaration stmt de la forme:

try try-block
finally finally-block

• L'affectation définitive de l'état de v au début de essayez-bloc est le même que l'affectation définitive de l'état de v au début de stmt.

• L'affectation définitive de l'état de v au début de enfin-bloc est le même que l'affectation définitive de l'état de v au début de stmt.

• L'affectation définitive de l'état de v à la fin de stmt est certainement affectée si (et seulement si), soit:
o v est définitivement attribué à la fin de essayez-bloc
o v est définitivement attribué à la fin de enfin-bloc
Si un flux de contrôle de transfert (comme un goto déclaration) qui commence dans les essayez-bloc, et se termine à l'extérieur de essayez-bloc, puis v est également considéré comme définitivement attribuées sur que le contrôle de flux de transfert si v est définitivement attribué à la fin de enfin-bloc. (Ce n'est pas seulement si—si v est certainement attribué pour une autre raison sur ce contrôle de flux de transfert, il est toujours considéré comme définitivement attribué.)

12.3.3.15 Try-catch-finally états

Définitive d'attribution de l'analyse pour une essayer-attraper-enfin instruction de la forme:

try try-block
catch ( ... ) catch-block-1
... 
catch ( ... ) catch-block-n
finally finally-block

est fait comme si l'énoncé ont été un essayer-enfin déclaration en joignant une essayer-attraper déclaration:

try { 
    try   
    try-block
    catch ( ... ) catch-block-1
    ...   
    catch ( ... ) catch-block-n
} 
finally finally-block

C'est largement plus facile à écrire, le débogage et la maintenance du code, qui est libre de messages d'erreur du compilateur, code-analyse des messages d'avertissement et de routine accepté exceptions (notamment les exceptions levées dans un endroit et accepté dans un autre). Parce que c'est plus facile, le code en moyenne, mieux écrit et moins buggé.

Pour moi, que programmeur et de la qualité de surcharge est le principal argument contre l'utilisation de try-catch pour le flux de processus.

L'ordinateur généraux des exceptions est insignifiante en comparaison, et généralement minuscules en termes de la capacité de l'application à rencontrer dans le monde réel des exigences de performance.

On peut lire dans les Langages de Programmation Pragmatique par Michael L. Scott que l'aujourd'hui les compilateurs ne pas ajouter de frais généraux dans le cas le plus courant, cela signifie que, lorsque aucune exception se produit. Ainsi, chaque travail est fait dans les temps de compilation.
Mais lorsqu'une exception est levée lors de l'exécution, compilateur a besoin pour effectuer une recherche binaire pour trouver la bonne exception et ce sera le cas pour chaque nouveau jet de ce que vous faite.

Mais des exceptions sont des exceptions et ce coût est parfaitement acceptable. Si vous essayez de faire la gestion des exceptions sans exceptions et utiliser retourner les codes d'erreur au lieu de cela, probablement, vous aurez besoin d'une instruction if pour chaque sous-programme, ce qui entraînera dans un vraiment en temps réel des frais généraux. Vous savez si la déclaration est converti à quelques instructions de montage, qui sera exécuté à chaque fois que vous entrez dans votre sous-routines.

Désolé pour mon anglais, espérons que cela vous aide. Cette information est basée sur la cité du livre, pour plus d'informations, reportez-vous au Chapitre 8.5 gestion des exceptions.