Discussion :

[le y@m's]

salut a tous,
je souhaiterai avoir quelques precisions sur la declaration de fonction inline.
Apr�s consultation de la faq, j'ai compris que la declaration des fonction inline peut augmenter
comme baisser les performances d'une apllication mais je n'ai pas bien saisi les raisons de ces comportements.
est-ce un trop grand nombre de fonction ou des fonctions appel�es trop souvent (ou les deux) qui peuvent reduire la perf ?
ou bien encore d'autres choses ?
(en partant du principe que ces fonctions ne comporte qu'1 seule ligne de code).
merci d'avance.

[tut]

l'utilisation de inline peut r�duire les perfs si elle engendre une augmentation de taille du code de l'executable de mani�re tr�s importante, pouvant par exemple, entra�ner une pagination de la m�moire, si tu n'as pas de bol.
Pour synt�tiser :

Il n'y a pas de r�ponse simple : vous devez essayer et voir ce qui est le mieux. Ne vous limitez pas � des r�ponses simplistes telles que "Ne jamais utiliser les fonctions inline" ou "Toujours utiliser les fonctions inline" ou "N'utiliser les fonctions inline que si le code fait moins de ... lignes de code". Ces r�gles arbitraires sont peut-�tre faciles � �crire, mais les r�sultats sont plus que d�cevants.

et encore plus simple : si tu as un compilateur digne de ce nom et correctement utilis�, il se chargera tout seul comme un grand de mettre les fonctions inline n�cessaires.

[Charlemagne]

Si la vitesse est importante, il vaut mieux avoir un ex�cutable plus gros.
Car d'apr�s mon exp�rience, Il n'y a rien de plus lent qu'un appel de fonction ou qu'un saut (if/for/while).
Le pipeline du processeur est bris� est �a coute cher en temps d'ex�cution. Plus le processeur est �volu� (pentium 4) plus c'est pire, m�me si le processeur est soi disant capable de faire une pr�-�valuation des conditions de saut.

[Selenite]

Si la vitesse est importante, il vaut mieux avoir un ex�cutable plus gros.
Car d'apr�s mon exp�rience, Il n'y a rien de plus lent qu'un appel de fonction ou qu'un saut (if/for/while).
Le pipeline du processeur est bris� est �a coute cher en temps d'ex�cution. Plus le processeur est �volu� (pentium 4) plus c'est pire, m�me si le processeur est soi disant capable de faire une pr�-�valuation des conditions de saut.

Il vaut mieux avoir un �x�cutable un petit peu plus gros. Mettre de grosses fonctions inline peut vraiment faire baisser les performances.
Quand � la pr�vison des saut conditionnels, la r�gle est simple: les sauts en avant sont consid�r�s comme n'�tant pas pris, les saut en arri�re si. (On rajoute � cela un petit peu de m�moire si un saut en avant � �t� pris, le processeur le saura pour la prochaine fois.)

[HRS]

si la fonction est appel�e dans une boucle qui se deroule un milliard de fois,
cela vaut peut-�tre le coup de la mettre inline. De toute fa�on, c'est le
compilateur qui d�cide de tenir compte ou non de cette directive

[b Oo]

De toute fa�on, c'est le
compilateur qui d�cide de tenir compte ou non de cette directive

Salut,
j'entends dire que le compilateur choisit si une fonction est inline ou non.
Pourtant je ne suis pas s�r que ce soit le cas, il me semble que lorsqu'une fonction est d�clar�e inline (ou d�finie dans une classe) alors elle est inline.

Personnellement, je mets une m�thode inline lorsque celle-ci fait par exemple :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
 
class A
{
    int a;
  public;
    int getInt() const { return a; }
};

Bonne soir�e.

b Oo

[Charlemagne]

En g�n�ral c'est bien le compilateur qui d�cide, mais il y a des options de compilation pour le mettre sur la voie.
Et puis sous Visual (puisqu'il programme sous Visual), il ya surtout la directive '__forceinline', mais c'est pas standard

[le y@m's]

Et puis sous Visual (puisqu'il programme sous Visual)

Depuis quand ? (j'utilise devcpp)

si la fonction est appel�e dans une boucle qui se deroule un milliard de fois,
cela vaut peut-�tre le coup de la mettre inline

Donc declarer inline une fonction appell�e fr�quemment a plutot tendance � augmenter les perfs

[Charlemagne]

D�sol�, j'ai mal lu, ou confondu avec quelqu'un d'autre. Il m'avait sembl� que tu �tais sous Visual.

Dans l'ensemble, je dirais ne pas h�siter � d�clarer une fonction en inline. De toute facon le compilateur n'en fait souvent qu'� sa t�te.
A part debugger le programme dans le mode release (c'est possible sous Visual ou Intel Compiler), je vois pas comment faire pour s'assurer qu'une fonction a bien �t� r�ellement mise inline.
Grace a la directive __forceinline, j'ai souvent des gains d'au moins 50%.

Finallement, je pense c'est un test de rapidit� de ton programme qui dictera quels options de compilation choisir

[le y@m's]

merci a tous pour vos reponses

[le y@m's]

je marque le sujet resolu mais faut pas hesiter � rajouter des commentaires.

[Selenite]

Voici deux cas:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
 
for ( ; ; )
    f(x);

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
 
f(a);
f(b);
f(c);
f(d);
f(e);
...

Dans le premier cas, mettre f en inline sera une bonne id�e. Dans le second cas, probablement non. A l'�x�cution du programme, charger le code est une op�ration qui coute du temps. Une fonction qui est beaucoup appel�e, mais pas peu de points d'appel est une bonne condidate � l'inline.
Essayez pour voir ce code:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
 
f(x);
f(x);

La premi�re ex�cution de f sera bien plus lente que la seconde.

[koushkov]

D�sol� de ressortir le sujet mais, si je comprends bien, utiliser des fonctions inline augmente le temps de chargement de l'exe et une fois qu'il est charg�, l'ex�cution est plus rapide. Il faut donc un bon compromis entre les deux.

Autrement dit, si j'utilise des fonctions qui font des tests sans arr�t, avec des boucles infinies, en la laissant ex�cuter longtemps (des dizaines d'heures), le mieux serait alors de mettre du inline partout.