42 votes

Pourquoi les blocs d'essai sont-ils chers?

J'ai entendu les conseils que vous devriez éviter de blocs try catch, si possible, car ils sont coûteux.

Ma question est précisément à propos de l' .NET plate-forme: Pourquoi les blocs try cher?

Résumé des Réponses:

Il y a clairement deux camps sur ce problème: ceux qui disent que les blocs try sont chers, et ceux qui disent "peut-être un tout petit peu".

Ceux qui disent que les blocs try sont chers normalement mentionner le "coût élevé" de dénouement de la pile d'appel. Personnellement, je ne suis pas convaincu par cet argument - spécialement après avoir lu sur la façon dont les exceptions les gestionnaires sont stockées ici.

Jon Skeet est assis sur le "peut-être un tout petit peu" de camp, et a écrit deux articles sur les exceptions et les performances que vous pouvez trouver ici.

Il y avait un article que j'ai trouvé extrêmement intéressant: il a parlé "d'autres" implications sur les performances des blocs try (pas nécessairement la mémoire ou le processeur de la consommation). Pierre Ritchie mentionne qu'il a constaté que le code à l'intérieur de blocs try n'est pas optimisé comme il avait autrement par le compilateur. Vous pouvez lire à ce sujet les conclusions de son rapport ici.

Enfin, il y a une entrée de blog à propos de la question de l'homme qui a mis en œuvre des exceptions dans le CLR. Allez jeter un coup d'oeil à Chris Brumme de l'article ici.

23voto

DaveK Points 2915

Les articles suivants devraient éclairer le sujet:

Est-ce que vous essayez ... de bloquer les blocs nuit aux performances d'exécution?

Conséquences sur les performances d'essayer / attraper / enfin

18voto

Bob King Points 12913

Ce n'est pas le bloc lui-même qui coûte cher, et il ne détecte même pas d'exception, mais le temps d'exécution qui décompresse la pile d'appels jusqu'à ce qu'il trouve un cadre de pile capable de gérer l'exception. Lancer une exception est assez léger, mais si le moteur d'exécution doit parcourir six cadres de pile (c'est-à-dire six appels de méthode de profondeur) pour trouver un gestionnaire d'exception approprié, éventuellement en exécutant finalement des blocs au fur et à mesure, vous risquez de constater un laps de temps considérable .

10voto

Scott Dorman Points 25000

Vous ne devriez pas éviter les blocs try/catch en tant que règle générale, vous ne sont pas correctement la manipulation des exceptions qui peuvent se produire. La gestion structurée des exceptions (SEH) est seulement coûteux lorsqu'une exception se produit en fait que le moteur d'exécution doit marcher la pile des appels à la recherche d'un gestionnaire catch, l'exécution de cette fonction (et il peut y avoir plus d'un), puis d'exécuter les enfin les blocs, puis revenir en arrière pour le code au bon endroit.

Les Exceptions ne sont pas destinés à être utilisés pour le contrôle de la logique du programme, mais plutôt d'indiquer les conditions d'erreur.

L'une des plus grandes idées fausses sur les exceptions, c'est qu'ils sont pour "des conditions exceptionnelles." La réalité c'est qu'ils sont pour la communication les conditions d'erreur. À partir d'un cadre la conception de point de vue, il n'y a pas de tels quelque chose comme "un état exceptionnel". Si une condition est exceptionnel ou pas de dépend du contexte d'utilisation, --- mais réutilisables bibliothèques rare de savoir comment ils seront utilisés. Par exemple, OutOfMemoryException peut-être exceptionnel pour une simple saisie de données d'application; il n'est pas si exceptionnel pour les applications en faisant leur propre gestion de la mémoire (par exemple, SQL server). En d'autres termes, un homme exceptionnel la condition est d'un autre homme chronique condition. [http://blogs.msdn.com/kcwalina/archive/2008/07/17/ExceptionalError.aspx]

5voto

Michael Petrotta Points 35647

Je pense que les gens vraiment surestimer le coût de performances de lever des exceptions. Oui, il y a un gain de performance, mais il est relativement petit.

J'ai couru le test suivant, lancer et attraper un million d'exceptions. Il a fallu environ 20 secondes sur mon Intel Core 2 Duo2.8 GHz. C'est environ 50K exceptions seconde. Si vous êtes lançant même une petite fraction de ce que, vous avez de l'architecture des problèmes.

Voici mon code:

using System;
using System.Diagnostics;

namespace Test
{
    class Program
    {
        static void Main(string[] args)
        {
            Stopwatch sw = Stopwatch.StartNew();
            for (int i = 0; i < 1000000; i++)
            {
                try
                {
                    throw new Exception();
                }
                catch {}
            }
            Console.WriteLine(sw.ElapsedMilliseconds);
            Console.Read();
        }
    }
}

5voto

Anthony Points 2537

Un bloc d'essai n'est pas cher du tout. Peu ou pas de frais sont encourus à moins qu'une exception ne soit levée. Et si une exception a été levée, c'est une circonstance exceptionnelle et vous ne vous souciez plus de la performance. Est-il important que votre programme prenne 0,001 seconde ou 1,0 seconde à tomber? Non. Ce qui compte, c'est la qualité des informations qui vous sont rapportées pour vous permettre de les corriger et d'empêcher qu'elles ne se reproduisent.

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: