18 Mai 2015

[Perf] C# et les Try / Catch

Je m’intéresse ici aux performances des blocs try/catch et notamment de leurs imbrications. On lit souvent que leur imbrication n’est pas recommandée. Vérifions-le.

Benchmark

Soit la méthode suivante DiviseParDeux:

(L’initialisation et l’utilisation de la variable « res » n’a pas de réel intérêt dans ce premier test).

 

Appelons cette méthode, avec et sans try/catch :

 Méthode sans try catch Méthode avec try catch

 

 

 

 

Faisons 10 millions d’appels de chacune.

Les résultats (en release) :

Avec Try / Catch : 38.913 ms
Sans Try / Catch : 35.148 ms

Ok, l’écart est faible.

Allons plus loin et essayons en imbriquant les try catch. Créons la méthode DiviseParDeuxAvecTry (identique à la méthode précédente DiviseParDeux, mais avec un bloc try/catch) :

 

 

Et la méthode qui l’appelle est :

 

Effectuons le même test que précédemment (en release): soit 10 millions d’appels.

Le résultat est de : 75.164 ms.

Et si l’on ajoute un troisième try catch on arrive à : 117.46 ms

Remarque : on voit sur ce simple exemple que l’on augmente le temps de traitement en imbriquant un try / catch. On a même réussi à doubler le temps de traitement !

Conclusion

Le but ici était de montrer que l’utilisation d’un simple try/catch n’est pas coûteux en soit, mais dès lors que l’on imbrique les Try/catch cela consomme plus.

Nous avons pour habitudes de voir des architectures dites « en couche ». C’est-à-dire qu’une méthode de la couche supérieure appelle une ou plusieurs méthodes de la couche inférieure, qui vont elles aussi appeler celles de la couche inférieure. On comprend rapidement qu’une utilisation disproportionnée de try/catch dans chacune des couches peut provoquer des pertes de performances. Je ne dis pas qu’il faille retirer tous les try/catch, mais plutôt de les gérer plus intelligemment et lorsque cela est nécessaire. Personnellement, je préconise de catcher les exceptions au niveau des couches supérieures.

Share