Performances des exceptions C++

Bonjour � tous,

Je vous pr�sente une nouvelle traduction de l'article de Vlad Lazarenko discutant des performances des exceptions en C++. Souvent, lorsque l'on �crit du code, on se demande l'impact des exceptions sur les performances de notre programme. Cet article apporte donc des �l�ments de r�ponse d�taill�s � cette question.

Performances des exceptions C++

:fleche: Avez-vous �vit� d'utiliser des exceptions pour pr�server les performances ?
:fleche: Dans quel cas avez vous pris cette d�cision ?

Il me semble avoir lu l'article auparavant mais le liens dans la page fran�aise n'a pas l'air de fonctionner (http://lazarenko.me/tips-and-tricks/...nd-performance) - mais peut �tre qu'il y a un problem d'ici, je suis au Japon.

Sinon, comme quasiment tout le monde dans les discussions, il ignore compl�tement le cas ou on desactive les exceptions et qu'on ne fais aucune verification d'erreur (on compte sur des tests massifs avant publication).

L'exemple du divis� est un peu bancale. Si un precondition est viol�, c'est plutot une assertion qui devrait etre lev�e.

Bonsoir,

tout d'abord merci pour la traduction!

Dans le billet, l'auteur �voque une gestion sans co�t des exceptions mais ne semble pas la d�crire. De quoi s'agit-il?

@Joel F : je n'ai pas compris pourquoi une assertion devrait �tre lev�e dans le cas particulier du divide. Cela ne va-t-il pas interrompre pr�matur�ment le d�roulement du programme si on fait cela?

Citation:

---

Envoy� par Aleph69

Bonsoir,

tout d'abord merci pour la traduction!

Dans le billet, l'auteur �voque une gestion sans co�t des exceptions mais ne semble pas la d�crire. De quoi s'agit-il?

---

En fait, c'est la m�thode qu'utilisent les compilateurs. La m�thode zero-cost et la m�thode setjmp/longjmp sont juste deux fa�ons pour le compilateur de compiler les exceptions, en fait.

Citation:

---

Envoy� par Aleph69

@Joel F : je n'ai pas compris pourquoi une assertion devrait �tre lev�e dans le cas particulier du divide. Cela ne va-t-il pas interrompre pr�matur�ment le d�roulement du programme si on fait cela?

---

En fait, Joel expliquait que si on appelle divide avec un d�nominateur de z�ro, alors l'erreur vient du d�v', et donc qu'il n'est pas g�nant de tout faire crasher.
Pour lui faire plaisir, on pourrait appeler la fonction divide_protected ; ou quelque chose du genre. ;)

Citation:

---

Envoy� par Ekleog

En fait, c'est la m�thode qu'utilisent les compilateurs. La m�thode zero-cost et la m�thode setjmp/longjmp sont juste deux fa�ons pour le compilateur de compiler les exceptions, en fait.

---

Ah oui, effectivement c'est pr�cis� dans le billet. :aie:
Y a-t-il un moyen de tester le choix fait par le compilateur?
Que font gcc et le compilateur de visual?

Citation:

---

Envoy� par Ekleog

En fait, Joel expliquait que si on appelle divide avec un d�nominateur de z�ro, alors l'erreur vient du d�v', et donc qu'il n'est pas g�nant de tout faire crasher.
Pour lui faire plaisir, on pourrait appeler la fonction divide_protected ; ou quelque chose du genre. ;)

---

Je ne suis pas tout � fait s�r de cela. La division par z�ro pour des flottants n'est pas forc�ment une erreur de d�veloppeur, elle appara�t dans plein de m�thodes num�riques, et je ne pourrais pas pr�tendre que ce n'est pas le cas non plus pour des entiers. Qu'est-ce qui t'am�ne � penser cela?

On parle de divisione enti�re par 0 qui sur les proc bien elev�e est un TRAP.
0.f/0.F ca vaut Nan.f on est bien d'accord.

BIen utiliser les exceptions ca va avec les utiliser la ou elles ont du sens; aka les postconditions. Les preconditions ca assert.

Oui, oui bien bien s�r. Je sais qu'en g�n�ral les compilateurs l�vent une assertion pour les entiers et par pour les flottants mais je ne vois pas ce qui justifie a priori cette distinction sachant que la norme indique bien qu'il s'agit d'un comportement ind�termin�. Je n'ai pas non plus d'argument en faveur du fait de lever une exception. C'est juste que vu ta remarque et le fait que tu ais d�velopp� une biblioth�que d'alg�bre lin�aire, je croyais que tu avais une bonne raison de lever une assertion pour les entiers et pas pour les flottants et je voulais juste en savoir plus! ;) Tout cela est un peu hors sujet donc j'arr�te l�!

0/0 c'est pas le compilo qui couine, mais le proc qui va TRAPPER.
0/0 c'ets indefini donc tu ne veux pas que ca se fasse du tout. La ou en reel, 0/0 est NaN et est bien d�fini.

Citation:

---

Envoy� par Joel F

BIen utiliser les exceptions ca va avec les utiliser la ou elles ont du sens; aka les postconditions. Les preconditions ca assert.

---

100% d'accord avec �a.

Placez-vous les r�gles de gestion et autres contraintes de coh�rence de base de donn�es dans les postconditions (vraie question inside)?

De base de donn�e? Personellement pas sp�cifiquement, mais les contraintes du model, quel que soit l'impl�mentation, oui.

La diff�rence c'est que selon le type de v�rification et le type d'impl�mentation, le model peut ou pas �tre v�rifi� en amont de la base de donn�e.


Je sais pas si �a r�ponds � ta question.

l'exemple utilise est tres bancal, il n'y a pas un destructeur a appeler et le code a executer est minimal.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

#include <iostream> struct S { ~S(); }; S::~S() { std::cout << "~S" << std::endl; } void foo(int i) { S s; if (i <= 0) throw "fail"; // Oui, c'est debile. foo(i - 1); } int main() { foo(5); }

---

Code:

---

1 2 3 4 5 6 7 8 9

(gdb) disas main Dump of assembler code for function main(): 0x0000000000400a00 <+0>: sub rsp,0x8 0x0000000000400a04 <+4>: mov edi,0x5 0x0000000000400a09 <+9>: call 0x400bb0 <foo(int)> 0x0000000000400a0e <+14>: xor eax,eax 0x0000000000400a10 <+16>: add rsp,0x8 0x0000000000400a14 <+20>: ret End of assembler dump.

---

=> Rien de particulier. Pas de try, normal. On pourrait mettre un try pour voir ce que �a donne, aussi :

Code:

---

1 2 3 4 5 6 7

int main() { try { foo(5); } catch(...) { std::cout << "(!!)" << std::endl; } }

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

(gdb) disas main Dump of assembler code for function main(): 0x0000000000400ba0 <+0>: push rbx 0x0000000000400ba1 <+1>: mov edi,0x5 0x0000000000400ba6 <+6>: call 0x400d80 <foo(int)> 0x0000000000400bab <+11>: xor eax,eax 0x0000000000400bad <+13>: pop rbx 0x0000000000400bae <+14>: ret 0x0000000000400baf <+15>: mov rdi,rax 0x0000000000400bb2 <+18>: call 0x400b60 <__cxa_begin_catch@plt> 0x0000000000400bb7 <+23>: mov esi,0x400e8c 0x0000000000400bbc <+28>: mov edi,0x601320 0x0000000000400bc1 <+33>: call 0x400af0 <_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc@plt> 0x0000000000400bc6 <+38>: mov rdi,rax 0x0000000000400bc9 <+41>: call 0x400b50 <_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_@plt> 0x0000000000400bce <+46>: call 0x400b40 <__cxa_end_catch@plt> 0x0000000000400bd3 <+51>: jmp 0x400bab <main()+11> 0x0000000000400bd5 <+53>: mov rbx,rax 0x0000000000400bd8 <+56>: call 0x400b40 <__cxa_end_catch@plt> 0x0000000000400bdd <+61>: mov rdi,rbx 0x0000000000400be0 <+64>: call 0x400b80 <_Unwind_Resume@plt> End of assembler dump.

---

A l'exception des sub/add rsp remplac�s par des push/pop ; le chemin d'ex�cution normal est le m�me.
Par contre, comme attendu, le chemin d'ex�cution exceptionnel est plus complexe.

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

(gdb) disas foo Dump of assembler code for function foo(int): 0x0000000000400bb0 <+0>: push rbx 0x0000000000400bb1 <+1>: sub rsp,0x10 0x0000000000400bb5 <+5>: test edi,edi 0x0000000000400bb7 <+7>: jle 0x400bd1 <foo(int)+33> 0x0000000000400bb9 <+9>: sub edi,0x1 0x0000000000400bbc <+12>: call 0x400bb0 <foo(int)> 0x0000000000400bc1 <+17>: lea rdi,[rsp+0xf] 0x0000000000400bc6 <+22>: call 0x400b40 <S::~S()> 0x0000000000400bcb <+27>: add rsp,0x10 0x0000000000400bcf <+31>: pop rbx 0x0000000000400bd0 <+32>: ret 0x0000000000400bd1 <+33>: mov edi,0x8 0x0000000000400bd6 <+38>: call 0x4009b0 <__cxa_allocate_exception@plt> 0x0000000000400bdb <+43>: xor edx,edx 0x0000000000400bdd <+45>: mov QWORD PTR [rax],0x400cb7 0x0000000000400be4 <+52>: mov esi,0x6013e0 0x0000000000400be9 <+57>: mov rdi,rax 0x0000000000400bec <+60>: call 0x4009c0 <__cxa_throw@plt> 0x0000000000400bf1 <+65>: lea rdi,[rsp+0xf] 0x0000000000400bf6 <+70>: mov rbx,rax 0x0000000000400bf9 <+73>: call 0x400b40 <S::~S()> 0x0000000000400bfe <+78>: mov rdi,rbx 0x0000000000400c01 <+81>: call 0x4009e0 <_Unwind_Resume@plt> End of assembler dump.

---

Le chemin du throw est assez lourd, comme on peut s'y attendre.
Il alloue, puis "throw", puis appelle le destructeur, et enfin appelle _Unwind_Resume@plt qui, je suppose, remonte la pile d'appel.

Si je comprends bien, voici ce qui se passe (g++) :

• __cxa_allocate_exception@plt alloue de l'espace pour une exception ;
• __cxa_throw@plt emploie cet espace pour y stocker toutes les donn�es de l'exception (type, contenu...) ;
• On appelle les destructeurs de tous les objets ;
• _Unwind_Result@plt remonte la pile � la recherche d'une fonction ayant un code de gestion des exceptions, c'est-�-dire d'un code situ� juste apr�s le ret ; puis il jmp dans ce code (il doit � avoir un pointeur vers le code dans une globale constante quelque part) ;
• Ce code commence par tester le type de l'exception ramass�e (test� avec std::string const & � la place de ...), soit il appelle _Unwind_Resume (�chec du match) ; soit il appelle __cxa_begin_catch ;
• __cxa_begin_catch... enregistre qu'on est entr� dans un catch ? __cxa_end_catch correspond... je ne connais pas leur utilit�... Peut-�tre __cxa_begin_catch dispatche-t-il vers le bon code de gestion d'erreurs ?
• Le code de gestion d'erreurs est appell� ;
• Si il y a un rethrow, les destructeurs sont appell�s et _Unwind_Resume@plt est r�appell� ;
• Sinon, le code retourne � son ex�cution normale ;
• Enfin, si aucun handler ne convient, _Unwind_Resume@plt est appell�, et on recommence un tour avec une fonction de moins sur la stack.

Est-ce un exemple suffisamment complexe ?

Non, dans ton premier exemple, ta fonction est appel�e avec une constante num�rique int�grale, le test est tr�s simple et est donc r�solu � la compilation (a tous les coups). Le compilo a du �liminer la branche qui fait le throw.

Si tu veux un exemple qui est plus probable:

1. fais en sorte que les donn�es � traiter viennent de l'ext�rieur, pour empecher le compilo de faire du traitement � la compilation
2. fais en sorte qu'il y ait plusieurs unit�s de compilations (.cpp)

L'id�al serait de faire un petit jeu, mais m�me comme �a, selon le type de performance n�cessaire, �a risque d'�tre difficile � mesurer.

Citation:

---

Envoy� par Klaim

Non, dans ton premier exemple, ta fonction est appel�e avec une constante num�rique int�grale, le test est tr�s simple et est donc r�solu � la compilation (a tous les coups). Le compilo a du �liminer la branche qui fait le throw.

---

Le throw �tant dans foo et non dans main, il est normal que dans le premier disas il n'y ait pas de branche, hein. Ou bien je comprends mal ?

Citation:

---

Si tu veux un exemple qui est plus probable:

1. fais en sorte que les donn�es � traiter viennent de l'ext�rieur, pour empecher le compilo de faire du traitement � la compilation
2. fais en sorte qu'il y ait plusieurs unit�s de compilations (.cpp)

L'id�al serait de faire un petit jeu, mais m�me comme �a, selon le type de performance n�cessaire, �a risque d'�tre difficile � mesurer.

---

Sauf qu'� en voir l'asm, il n'y a pas tellement d'optimisations faites.
Dans chaque fonction, on voit bien chaque branche... on reconna�t m�me presque le code C++ directement dans l'asm (bon, d'accord, il faut regarder de loin, mais si on e fait attention qu'aux call on s'y retrouve pas mal -- � part les flux qui font un bazar assez effrayant).
Du coup, je ne suis pas s�r qu'on gagnerait beaucoup en r�alisme en complexifiant l'affaire. (loi des 80/20)

Citation:

---

Envoy� par Ekleog

Sauf qu'� en voir l'asm, il n'y a pas tellement d'optimisations faites.)

---

Les as-tu bien toutes demand�es au moment de la compil ?

Citation:

---

Envoy� par Ekleog

Le throw �tant dans foo et non dans main, il est normal que dans le premier disas il n'y ait pas de branche, hein. Ou bien je comprends mal ?

---

Ca n'a rien a voir. Ta fonction est d�finie dans la meme unit�e de compilation, le compilo peut inliner, et m�me si il n'inline pas, il peut imm�diatement deviner que la valeur pass�e est constante et donc qu'il n'y a qu'un seul chemin possible et donc qu'il peut �liminer le reste, d'ou le code que tu obtiens.

Citation:

---

Sauf qu'� en voir l'asm, il n'y a pas tellement d'optimisations faites.
Dans chaque fonction, on voit bien chaque branche... on reconna�t m�me presque le code C++ directement dans l'asm (bon, d'accord, il faut regarder de loin, mais si on e fait attention qu'aux call on s'y retrouve pas mal -- � part les flux qui font un bazar assez effrayant).
Du coup, je ne suis pas s�r qu'on gagnerait beaucoup en r�alisme en complexifiant l'affaire. (loi des 80/20)

---

Si, parcequ'il est question de comparaison. Le souci c'est que dans ton premier exemple, il est tellement simple (le throw est vir�) qu'il n'est pas un bon point de comparaison.
Et aussi parceque l'impact de la pr�sence de throw (sans try catch) n'est r�llement visible que dans des applications r��lles, a cause de leur complexit� qui n'est jamais aussi simple que ton exemple. Notemment parcequ'il ya, par nature, �norm�ment plus de sauts, de branches et de d�coupages en petites fonctions, de manipulations (visible ou pas) de pointeurs, etc.

Selon le type d'implication, le cout peut �tre tout a fait diff�rent.
Ah oui aussi: il faut comparer avec une application qui ne fait pas de throw explicite (mais qui utilise la STL). Tu vas voir �a a un autre gout.

Citation:

---

Envoy� par jblecanard

Les as-tu bien toutes demand�es au moment de la compil ?

---

De m�moire, la command� �tait g++ -g a.cpp avec alias g++='LANG="C" g++ -std=c++11 -O2 -Wall -Wextra -pedantic' (oui, j'ai ramass� un warning unused s)

Citation:

---

Envoy� par Klaim

Ca n'a rien a voir. Ta fonction est d�finie dans la meme unit�e de compilation, le compilo peut inliner, et m�me si il n'inline pas, il peut imm�diatement deviner que la valeur pass�e est constante et donc qu'il n'y a qu'un seul chemin possible et donc qu'il peut �liminer le reste, d'ou le code que tu obtiens.

---

Code:

---

1 2 3 4 5 6 7 8 9 10

// a.cpp #include <iostream> void bar(int i); int main() { try { bar(5); } catch(std::string const &) { std::cout << "(!!)" << std::endl; } }

---

Code:

---

1 2 3 4 5

// b.cpp void foo(int i); void bar(int i) { foo(i); }

---

Code:

---

1 2 3 4 5 6 7 8 9

// c.cpp struct S { ~S(); }; void foo(int i) { S s; if (i <= 0) throw "fail"; // Oui, c'est debile. foo(i - 1); }

---

Code:

---

1 2 3 4 5 6 7 8

// d.cpp #include <iostream> struct S { ~S(); }; S::~S() { std::cout << "~S" << std::endl; }

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11

tmp$ # compilation tmp$ alias g++ alias g++='LANG="C" g++ -std=c++11 -O2 -Wall -Wextra -pedantic' tmp$ g++ -c a.cpp -o a.o tmp$ g++ -c b.cpp -o b.o tmp$ g++ -c c.cpp -o c.o c.cpp: In function 'void foo(int)': c.cpp:5:6: warning: unused variable 's' [-Wunused-variable] tmp$ g++ -c d.cpp -o d.o tmp$ g++ a.o b.o c.o d.o -o exec tmp$ gdb exec

---

=> (M�me pas -flto ni -O3, tu noteras.)

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

(gdb) disas main Dump of assembler code for function main: 0x0000000000400bf0 <+0>: push rbx 0x0000000000400bf1 <+1>: mov edi,0x5 0x0000000000400bf6 <+6>: call 0x400da0 <_Z3bari> 0x0000000000400bfb <+11>: xor eax,eax 0x0000000000400bfd <+13>: pop rbx 0x0000000000400bfe <+14>: ret 0x0000000000400bff <+15>: sub rdx,0x1 0x0000000000400c03 <+19>: mov rdi,rax 0x0000000000400c06 <+22>: je 0x400c0d <main+29> 0x0000000000400c08 <+24>: call 0x400bd0 <_Unwind_Resume@plt> 0x0000000000400c0d <+29>: call 0x400bb0 <__cxa_begin_catch@plt> 0x0000000000400c12 <+34>: mov esi,0x400f24 0x0000000000400c17 <+39>: mov edi,0x601480 0x0000000000400c1c <+44>: call 0x400b40 <_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc@plt> 0x0000000000400c21 <+49>: mov rdi,rax 0x0000000000400c24 <+52>: call 0x400ba0 <_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_@plt> 0x0000000000400c29 <+57>: call 0x400b90 <__cxa_end_catch@plt> 0x0000000000400c2e <+62>: xchg ax,ax 0x0000000000400c30 <+64>: jmp 0x400bfb <main+11> 0x0000000000400c32 <+66>: mov rbx,rax 0x0000000000400c35 <+69>: call 0x400b90 <__cxa_end_catch@plt> 0x0000000000400c3a <+74>: mov rdi,rbx 0x0000000000400c3d <+77>: call 0x400bd0 <_Unwind_Resume@plt> End of assembler dump.

---

=> Me semble bien proche de l'exemple pr�c�dent

Code:

---

1 2 3 4

(gdb) disas bar Dump of assembler code for function _Z3bari: 0x0000000000400da0 <+0>: jmp 0x400db0 <_Z3fooi> End of assembler dump.

---

=> J'ai rajout� la fonction ; elle n'a rien � voir avec les erreurs et n'a pas � y g�rer quoi que ce soit.

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

(gdb) disas foo Dump of assembler code for function _Z3fooi: 0x0000000000400db0 <+0>: push rbx 0x0000000000400db1 <+1>: sub rsp,0x10 0x0000000000400db5 <+5>: test edi,edi 0x0000000000400db7 <+7>: jle 0x400dd1 <_Z3fooi+33> 0x0000000000400db9 <+9>: sub edi,0x1 0x0000000000400dbc <+12>: call 0x400db0 <_Z3fooi> 0x0000000000400dc1 <+17>: lea rdi,[rsp+0xf] 0x0000000000400dc6 <+22>: call 0x400e10 <_ZN1SD2Ev> 0x0000000000400dcb <+27>: add rsp,0x10 0x0000000000400dcf <+31>: pop rbx 0x0000000000400dd0 <+32>: ret 0x0000000000400dd1 <+33>: mov edi,0x8 0x0000000000400dd6 <+38>: call 0x400b70 <__cxa_allocate_exception@plt> 0x0000000000400ddb <+43>: xor edx,edx 0x0000000000400ddd <+45>: mov QWORD PTR [rax],0x400f43 0x0000000000400de4 <+52>: mov esi,0x6015a0 0x0000000000400de9 <+57>: mov rdi,rax 0x0000000000400dec <+60>: call 0x400b80 <__cxa_throw@plt> 0x0000000000400df1 <+65>: lea rdi,[rsp+0xf] 0x0000000000400df6 <+70>: mov rbx,rax 0x0000000000400df9 <+73>: call 0x400e10 <_ZN1SD2Ev> 0x0000000000400dfe <+78>: mov rdi,rbx 0x0000000000400e01 <+81>: call 0x400bd0 <_Unwind_Resume@plt> End of assembler dump.

---

=> Me semble identique � la version pr�c�dente.

=> A part que cette fois il ne me demangle plus les fonctions (je me demande bien pourquoi, d'ailleurs, vu que je n'ai rien modifi�), aucune diff�rence.

Citation:

---

Si, parcequ'il est question de comparaison. Le souci c'est que dans ton premier exemple, il est tellement simple (le throw est vir�) qu'il n'est pas un bon point de comparaison.

---

C'est d'ailleurs pour �a que j'ai fait un deuxi�me exemple, hein. :�

Citation:

---

Et aussi parceque l'impact de la pr�sence de throw (sans try catch) n'est r�llement visible que dans des applications r��lles, a cause de leur complexit� qui n'est jamais aussi simple que ton exemple. Notemment parcequ'il ya, par nature, �norm�ment plus de sauts, de branches et de d�coupages en petites fonctions, de manipulations (visible ou pas) de pointeurs, etc.

---

Mes fonctions ne sont pas assez petites ? 8O

Citation:

---

Selon le type d'implication, le cout peut �tre tout a fait diff�rent.

---

implication ?

Citation:

---

Ah oui aussi: il faut comparer avec une application qui ne fait pas de throw explicite (mais qui utilise la STL). Tu vas voir �a a un autre gout.

---

Pourquoi la SL aurait-elle un r�sultat diff�rent ? A part l'inline qui rend l'assembleur illisible, je ne vois pas ce qui devrait faire que �a change. Surtout vu que la SL est impl�ment�e surtout en headers, et que dans ces headers on voit des throw. Bon, ils sont sous la forme de __throw_out_of_range ; mais je suppose que l'impl�mentation est tr�s similaire.

Regardons :

Code:

---

1 2 3 4 5 6 7 8

(gdb) disas _ZSt16__throw_bad_castv Dump of assembler code for function _ZSt16__throw_bad_castv@plt: 0x0000000000400ad0 <+0>: jmp QWORD PTR [rip+0x2008a2] # 0x601378 <[email protected]> 0x0000000000400ad6 <+6>: push 0x0 0x0000000000400adb <+11>: jmp 0x400ac0 End of assembler dump. (gdb) x/a 0x601378 0x601378 <[email protected]>: 0x400ad6 <_ZSt16__throw_bad_castv@plt+6>

---

Bon, c'est bizarre cette fa�on de jmp � l'instruction suivante, mais bon...

Code:

---

1 2 3 4 5

(gdb) x/2i 0x400ac0 0x400ac0: push QWORD PTR [rip+0x2008a2] # 0x601368 <_GLOBAL_OFFSET_TABLE_+8> 0x400ac6: jmp QWORD PTR [rip+0x2008a4] # 0x601370 <_GLOBAL_OFFSET_TABLE_+16> (gdb) x/a 0x601370 0x601370 <_GLOBAL_OFFSET_TABLE_+16>: 0x0

---

Et l�... je ne comprends pas. Pourquoi un jmp 0x0 ?
Je suppose que la GOT doit �tre manipul�e d'une fa�on ou d'une autre par les fonctions _start ou ld-linux.so ou autre... m�me si je croyais me souvenir qu'elle �tait statique.

Ce que je veux dire c'est qu'il faut comparer ce qui est comparable. Une trop petite application ne reflette pas les diff�rences de performance trouv�s sur les applications en cours de dev ou finies.

Ces exemples sont trop simples parcequ'ils ne sont pas aussi complexe qu'un bete shoot them up par exemple.

Donc, en gros, il faut vraiment tester sur une application complete.

Mais selon le type d'applications, tu vas avoir des goulots d'etranglement diff�rents, et les variations de perfs potentielles li�es aux exceptions vont aussi varier.

Donc en gros, pour avoir un test vraiment probant il faut soit:

1. une appli d�j� complete qui a des macro pour pouvoir comparer les diff�rents cas
2. ecrire cette appli si elle n'existe pas
3. avoir des diff�rentes versions de l'appli ou differentes applis qui soient construitent avec une architecture totalement diff�rente.

ET les comparer.

C'est tr�s chiant a faire, c'est pour �a que personne le fais. Mais quand t'as, par exemple, un jeu complet, et que tu tests la diff�rence entre avec et sans exceptions , sans avoir �cris aucun throw ou try/catch, la derni�re fois que j'ai essay� j'ai gagn� en perf en enlevant la gestion des exception (qui n'�tait pas utilis�, sauf dans la stl).

Donc faudrait pouvoir refaire le m�me genre de test avec les compilos r�cents.