exeption et performance

Version imprimable

02/07/2007, 11h33
yan

exeption et performance

Bonjour,
est il vrai que les exceptions plombe les performance d'un code?

merci
02/07/2007, 11h55
ZaaN

je sais pas exactement, mais on peut penser que oui car instruction en plus = temps en plus... Mais bon c'est pas non plus un calcul matricielle...

mais meme si c'était faux, un code qui devrait générer des exceptions et qui ne le fais pas, ne sers pas a grand choses à mon avis...
02/07/2007, 12h07
Jean-Marc.Bourguet

En gros, il y a differentes techniques pour implementer les exceptions. Elles offrent des compromis differents entre "surcout du a la possibilite d'avoir des exceptions quand il n'y a pas d'exception" et "cout de l'exception quand elle est presente". Une technique en particulier permet d'avoir un surcout en l'absence d'exception quasiment nul (des effets indirects sur les optimisations).

Certains OS ont aussi une notion d'exception. Lier les exceptions du C++ a celle de l'OS a alors des avantages -- compatibilite interlangage plus forte par exemple -- mais aussi des inconveniants -- on ne peut pas utiliser le compromis qu'on voudrait, parfois il existe pour le C++ des methodes qui sont meilleures sur les deux tableaux.

Naturellement, il faut comparer le cout des exceptions avec celui des alternatives qui ne sont pas gratuites non plus.
02/07/2007, 14h10
yan

Citation:

Envoyé par ZaaN

mais meme si c'était faux, un code qui devrait générer des exceptions et qui ne le fais pas, ne sers pas a grand choses à mon avis...

Ma question et pour la gestion d'erreur dans mes class. Comme il y as plusieurs philosophie de gestion d'erreur, je me demandé si les exeption sont lent ou non.
02/07/2007, 14h19
Aurelien.Regat-Barrel

Tu as tant d'erreurs exceptionnelles que ca pour que les exceptions aient un impact significatif sur les performances de ton logiciel ?
http://gamearchitect.net/Articles/Ex...rrorCodes.html
02/07/2007, 15h43
yan

Citation:

Envoyé par Aurelien.Regat-Barrel

Tu as tant d'erreurs exceptionnelles que ca pour que les exceptions aient un impact significatif sur les performances de ton logiciel ?

C'est plus pour de la culture générale.
Avant de dire "les exeptions c'est cool", c'est bien de le savoir pourquoi. Et quand se sont les perf (lancer de rayon, traitement image ...) qui rentre en jeux, ça peut jouer sur la philosophie utilisé pour les erreurs.

merci pour le lien
02/07/2007, 20h17
loufoque

Voir ce fil très poussé sur comp.lang.c++.moderated
http://groups.google.com/group/comp....4c9b3e3509403/

Certaines implémentations n'ont aucun coût en performance dans le cas où aucune erreur ne survient (quand aucune exception n'est levée).
Ce qui signifie donc que c'est plus performant que des if/else et valeurs de retour dans ce cas.

Citation:

Une technique en particulier permet d'avoir un surcout en l'absence d'exception quasiment nul (des effets indirects sur les optimisations).

D'après le thread que je viens de mentionner, on peut même avoir un surcoût parfaitement nul, du moins en temps d'exécution.
03/07/2007, 15h35
yan

merci pour les reponses
04/07/2007, 00h19
Luc Hermitte

J'étais tombé sur cela http://gamearchitect.net/Articles/Ex...rrorCodes.html
qui est une approche assez pratique et ciblée.

À l'occasion, je lirai le fil sur clc++m, merci pour le lien.
04/07/2007, 03h41
koala01

Salut,

Cela ne fera sans doute pas avancer le débat, mais je me permets de vous livrer le fruit de ma réflection... Meme s'il est relativement simpliste en son genre.

En toute logique, une exception est lancée quand un événement qui n'aurait pas du arriver - et ce, quelle que soit la raison - survient.

Le résultat direct, c'est que l'état dans lequel se trouve l'application ne correspond plus à l'état dans lequel elle est sensée se trouver...

Si l'application ne retrouve pas rapidement un état normal, cela pourra mener à des catastrophes, que ce soit du fait d'aberrations de résultats ou du fait du plantage pur et simple de l'application.

Des lors, et meme si le fait de lancer une exception - et sans doute aussi de la gérer - venait à couter énormément de temps, n'est il pas sensé d'estimer préférable de prendre le temps qu'il faut pour que l'application retrouve un état correct :question:

Maintenant, je n'ai pris en compte que la perte de temps encourrue par le fait qu'une exception survienne... Et je présumes que, la question portait sur les pertes de performances dues au fait de la traquer... et sans doute, car c'est la regle générale espérée, quand elles ne surviennent justement pas :P
04/07/2007, 07h29
Aurelien.Regat-Barrel
Moi aussi j'ai pas mal réfléchi et me suis beaucoup documenté sur le sujet a un moment :D
Les exceptions ne sont qu'un mécanisme de transport des erreurs. J'étais tombé sur un excellent article débatant autour de ca:
Code:

1 2 3 4 5 6 7 8 9 10 11 std::exception test1() { if ( error ) return std::exception( "erreur" ); } #define ERROR 1 void test2() { if ( error ) throw ERROR; }
Une classe exception peut etre utilisée comme code de retour, et un code d'erreur comme exception...

La vraie question qu'il faut se poser est : qui va traiter mon erreur ? Si l'appelant de la fonction est le plus a meme de réagir a l'erreur, un code de retour est préférable. Sinon, une exception peut etre judicieuse.
Pour moi, les codes de retour sont le chemin des erreurs classiques attendues, et les exceptions un mécanisme d'erreur parallele, plus grave, moins prévisible et souvent difficile a résoudre.
04/07/2007, 08h29
poukill

Citation:

Envoyé par Aurelien.Regat-Barrel

La vraie question qu'il faut se poser est : qui va traiter mon erreur ? Si l'appelant de la fonction est le plus a meme de réagir a l'erreur, un code de retour est préférable. Sinon, une exception peut etre judicieuse.

Il y a, je pense, des cas où l'appelant peut être prévenu par un mécanisme d'exception.
Dans un de mes modules récemment, je devais récupérer un fichier sur un serveur, le décompresser si nécéssaire (car tous les fichiers n'étaient pas compressés), puis appliquer des traitements dessus...
J'ai choisi la méthode de:
1) Tenter la décompression avec Boost::gzip
2) Si OK tant mieux, on continue. Sinon boost lance une exception de mauvais format d'en-tête. L'exception est attrapée puis relancée pour que l'appelant l'attrappe à son tour.
3) L'appelant sait alors que le fichier n'est pas compressé et peut donc travailler directement dessus!

Parfois, la meilleure méthode pour savoir si on peut faire quelquechose, c'est de la tenter. (cf inversion de matrices !)
04/07/2007, 08h59
nikko34

Citation:

Envoyé par poukill

2) Si OK tant mieux, on continue. Sinon boost lance une exception de mauvais format d'en-tête. L'exception est attrapée puis relancée pour que l'appelant l'attrappe à son tour.

pourquoi l'attrapper si c'est pour la relancer après alors que c'est le comportement par défaut? A moins qu'il n'y ait un traitement spécifique..
04/07/2007, 09h26
Alp

Pour qu'elle soit attrappée par le code qui appelle la fonction qui vient de l'attrapper.
04/07/2007, 10h23
loufoque

Les exceptions n'ont pas besoin d'être appelées puis relancées pour être propagées à l'appelant.
C'est tout l'intérêt.
04/07/2007, 10h30
poukill

Euh... ça me ferait mettre un bloc try{ } sans catch dans la fonction appelé.
Le bloc catch serait uniquement dans la fonction appelante c'est bien ça?
04/07/2007, 10h50
Laurent Gomila

Citation:

Envoyé par poukill

Euh... ça me ferait mettre un bloc try{ } sans catch dans la fonction appelé.
Le bloc catch serait uniquement dans la fonction appelante c'est bien ça?

Pas besoin de try tout seul (d'ailleurs ça n'aurait aucun sens), l'exception remontera toute seule comme une grande jusqu'au premier catch correspondant.
04/07/2007, 11h20
poukill

Bon... :oops:
Encore une boulette de Poukill !

Merci Laurent! :ccool:

En fait, tu ne dois mettre un bloc catch (et son try correspondant) que si tu veux/dois gérer quelque en cas d'exception, et que cette gestion ne peut pas etre remise plus tard...

Ainsi, il se peut que, dans l'ordre d'appel des fonctions, tu ne dispose pas tout de suite des informations nécessaire à la gestion de l'exception

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
void fonct1()
{
    /* ce n'est que dans fonct1 qu'on peut traiter l'exception */
    try
    {
        fonct2();
    }
    catch(ton_exeption &e)
    {
        /* traitement de l'exeption */
    }
}
void fonct2()
{
    /* fonct2() n'a pas tous les éléments pour traiter l'exeption */
    fonct3();
}
void fonct3()
{
    /* C'est ici qu'on décide de lancer l'exeption */
    if (a==0)
        throw ton_exeption;
}

Par contre, il se peut que aussi bien fonct3 que fonct2 doivent prendre en charge *une partie* de la gestion de l'exeption et que le système ne revienne dans un état normal qu'apres que fonct1 aie pris en charge la fin de la gestion de l'exeption...

A ce moment là, cela devient:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
 
void fonct1()
{
    try
    {
        fonct2();
    }
    catch(exept2 &e)
   {
        /* fin du traitement de l'exeption */
   }
}
void fonct2()
{
    try
    {
        fonct3();
    }
    catch(exeption &)
    {
         /* partie du traitement */
         /* on relance l'exeption apres traitement, et rien n'oblige à 
          * relancer la meme exeption ;) */
         throw exept2(/*...*/);
    }
}
void fonct3()
{
    try
    {
        /* c'est ici que l'exeption "primaire" survient
        if(a==0)
            throw exeption(/*...*/);
    }
    catch(exeption &e)
    {
        /*fonct3 peut gérer une partie de l'exeption... et la relancer pour
         *la fonction appelante */
        throw e;
    }
}

Et bien sur, entre ces deux extrème, il y a toutes les variations possible ;)

04/07/2007, 22h35
yan

Donc au final, utiliser les exeption pour tout type d'erreur est un bonne methode?
ou faut 'il laisser les execptions au cas grave, et faire des retour d'erreur pour le reste?
ou c'est au choix?

Citation:

Envoyé par Mongaulois

Donc au final, utiliser les exeption pour tout type d'erreur est un bonne methode?

Non.
http://www.parashift.com/c++-faq-lit...html#faq-17.12

Le cas typique est une classe fichier:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 File f; try { f.open( "toto.txt" ); f.write( "Hello!" ); } catch ( const FileNotFoundException & e ) { throw IOError(); } catch ( const FileAccessError & e ) { throw IOError(); }
Code:

1 2 3 4 5 6 File f; if ( f.open( "toto.txt" ) ) { return f.write( "Hello!" ); } return false;
Si l'erreur est a destination de l'appelant de ta fonction, un simple code de retour simplifie l'utilisation. Maintenant, note que dans le 2eme cas File peut lever bad_alloc par exemple, mais comme l'appelant ne peut pas y faire grand chose, il laisse filer vers les plus hautes spheres...

05/07/2007, 13h24
yan

ok, merci.
Ca comme a devenir plus claire pour moi.
05/07/2007, 14h38
loufoque

Oui enfin dans certains cas la non existence du fichier est un cas exceptionnel
05/07/2007, 15h01
Aurelien.Regat-Barrel
Oui, mais ce n'est pas a la classe fichier de le décider, mais a son utilisateur. Le role d'une classe fichier est de permettre de manipuler un fichier, pas de décider s'il doit exister ou pas.
Code:

1 2 3 4 if ( !f.open( "mustexists.txt" ) ) { throw FileIsMissingException(); }
sauf si tu codes une classe FileWhichMustExists...:mrgreen:
29/01/2008, 18h03
Médinoc

D'accord avec Aurelien, sauf que je serais plus du genre à y aller fonction par fonction, généralement avec un paramètre...

Code:

void open(const std::string &fileName, bool bThrow);

Dans ce cas je ne vois pas bien l'intérêt du try/catch :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 File f; try { f.open( "toto.txt" ); f.write( "Hello!" ); } catch ( const FileNotFoundException & e ) { throw IOError(); } catch ( const FileAccessError & e ) { throw IOError(); }
J'imagine que IOError est une classe mere de FileNotFoundException et FileAccessError, et donc qu'on peut simplifier le code comme ça :
Code:

1 2 3 File f; f.open( "toto.txt" ); f.write( "Hello!" );
Et donc laisser l'appellant gérer l'erreur (par un try/catch), ce qui me semble plus pratique que la solution :
Code:

1 2 3 4 5 6 File f; if ( f.open( "toto.txt" ) ) { return f.write( "Hello!" ); } return false;
non :? ?

29/01/2008, 22h33
Médinoc

Surtout que le throw IOError() provoque la perte d'informations des exceptions précédentes...

Un avantage des plate-formes comme .Net et Java, où l'on peut chaîner les exceptions sans problème...
29/01/2008, 22h56
JolyLoic

Rien n'empêche les exceptions C++ d'avoir aussi une notion de chaînage d'exceptions. Ca n'a rien de compliqué à mettre en place. C'est juste que les classes standard ne l'ont pas.
30/01/2008, 08h51
poukill

[Mode Un Peu Hors Sujet]
En parlant de Java, je me pose la question suivante : pourquoi en Java il y a autant d'outils disponibles en standard (y compris IHM avec Swing), alors que le C++ est à la traîne (même avec l'ajout récent du TR1) ?
[/Mode Un Peu Hors Sujet]
30/01/2008, 09h01
yan

Citation:

Envoyé par poukill

[Mode Un Peu Hors Sujet]
En parlant de Java, je me pose la question suivante : pourquoi en Java il y a autant d'outils disponibles en standard (y compris IHM avec Swing), alors que le C++ est à la traîne (même avec l'ajout récent du TR1) ?
[/Mode Un Peu Hors Sujet]

Sûrement pour des raison de marketing. Vendre un nouveau language sans aucun outils, c'est pas trés attirant...
30/01/2008, 09h29
Jean-Marc.Bourguet

Citation:

Envoyé par poukill

[Mode Un Peu Hors Sujet]
En parlant de Java, je me pose la question suivante : pourquoi en Java il y a autant d'outils disponibles en standard (y compris IHM avec Swing), alors que le C++ est à la traîne (même avec l'ajout récent du TR1) ?
[/Mode Un Peu Hors Sujet]

Ca a ete discutte en long, en large et en profondeur, jusqu'a plus soif et ad nauseam ici. Donnons quand meme quelques pistes:
1/ Les processus d'evolution sont tres differents
2/ Les contextes dans lesquels ces processus prennent place sont differents
3/ Pour donner un point plus specifique: il y a trop d'interets deja investis dans des solutions non standards divergentes.
30/01/2008, 09h57
poukill

OK j'ai commencé à lire le thread, mais je pense pas avoir fini avant la semaine prochaine... Merci en tout cas pour le lien ... 8-)