Discussion :

[vladvad]

Salut

En C#, il semblerait qu'il y aient des pertes de perfos (en vitesse) liées à l'utilisation des instructions des try / catch.

Par contre, je n'ai trouvé aucun article les chiffrant ...

Quel est votre avis et votre expérience sur la question ?

[Chubyone]

Et bien il ne faut placer un try catch que s'il est nécessaire, dans un premier temps... Si tu souhaites arreter la levée de l'Exception ou si tu souhaites t'en occuper c'est bien, mais si c'est pour faire un catch{ throw; } ca n'a pas énormément d'intérêt.


Pour ce qui est des perfs et des chiffres purs, j'ai lu ici même (je ne sais plus de qui, et je ne connaissais pas ces sources -_-') que le try n'impactait pas réellement les performances, mais plutôt le catch lui même : la création de l'Exception, de la trace, du cast... Bref, la perf s'écroule lors de la levée de l'Exception (et ca se ressent humainement).
(En même temps, c'est bien une exception, alors pourquoi cela devrait il speeder du feu de dieu? Il faut bien un contre coup à la possibilité d'intercepter une erreur sans tout péter...)

Peut être que tu t'intéresse de plus prêts aux exceptions car tu les maitrises déjà, mais si ce n'est pas le cas, j'aime bien cet article :
http://gilles.tourreau.fr/dotnet/dot...us_dotnet.html


Je rajouterais tout de même que je suis presque sur qu'avant de s'intéresser au problème de perfs des try/catch il y a milles fois plus urgent à optimiser dans le dit code


Mais cela dit, c'est vrai que quelques chiffres peuvent être sympa à analyser...

Tu as un contexte particulier pour t'intéresser de prêts aux perfs des try/catch?

[Guulh]

Yep, comme le dit Chubyone, si une exception est levée, c'est qu'il y a un problème relativement grave, donc on est dans une phase où ce n'est pas la perf qui prime...

[Chubyone]

Ici tu as quelques tests / analyses / conclusions du pourquoi du comment, le tout vis à vis de la relativité du truc :

http://www.codeproject.com/KB/except...rformance.aspx

(en gros : qu'est ce que coute relativement une exception levée à cause d'un problème d'accès disque?...)

Et il rappel une petite annotation que je ne trouvais plus :
http://blogs.msdn.com/kcwalina/archi...onalError.aspx

KRZYSZTOF CWALINA
One of the biggest misconceptions about exceptions is that they are for “exceptional conditions.” The reality is that they are for communicating error conditions. From a framework design perspective, there is no such thing as an “exceptional condition”. Whether a condition is exceptional or not depends on the context of usage, --- but reusable libraries rarely know how they will be used. For example, OutOfMemoryException might be exceptional for a simple data entry application; it’s not so exceptional for applications doing their own memory management (e.g. SQL server). In other words, one man’s exceptional condition is another man’s chronic condition.

Les exceptions : on tombe dedans des qu'on est un petit en .net, et je me demande si "les maitriser" ne relève pas de l'utopie...

C'est une partie tellement énorme et si (trop) peu étudié...

[vladvad]

Merci pour ces explications et ces liens , je vais les lire et je ferai mes commentaires ...

En fait, mon problème, c'est surtout la perte éventuelle de perfs avec try / catch si il n'y a jamais d'exception levée !!! (on mettrait alors des try / catch au cas où ...). En particulier dans une boucle appelée des milliers de fois ...

[Pol63]

on est à 10ms près sur certaines traitement, et on met des try catch dans 90% de nos sub et property quand meme
(on ne veut pas que l'appli s'arrete non plus...)
comme le prouve le lien codeproject de Chubyone, sans exception de levée y a pas énormément de différences ... dans le pire des cas mettre 30 euros de plus dans le pc pour avoir les meme perf et les try catch

[harz62]

Par contre si tu dois faire un conversion utilise la méthode TryParse au lieu de catcher la conversion, tu aura de meilleures performances.