Bonsoir,
Je me pose une question sur le "coût" en terme de rapidité des appels "en
cascade".
Vous avez par exemple une variable
a.b.c.d
qui représente un type X* possédant une fonction FaireQuelqueChose(int)
Vous feriez :
A/
for(int i=0;i<100000;++i)
a.b.c.d->FaireQuelqueChose(i);
ou
B/
X *ptr=a.b.c.d;
for(int i=0;i<100000;++i)
ptr->FaireQuelqueChose(i);
Il ne faut pas chercher de sens à l'exemple, c'est juste pour illustrer mon
propos.
Personnellement, s'il y a beaucoup d'itérations, je choisirais la seconde
solution.
Et vous ?
Marc
Je me pose une question sur le "coût" en terme de rapidité des appels "en cascade".
M'est avis que ça dépend fortement du compilateur, des options de compilations, des capacités du processeur, etc.
Le plus simple est de mesurer le temps d'exécution. Et si tu ne vois aucune différence mesurable, ce n'est pas forcément par hasard.
Wykaaa
MGN a écrit :
Bonsoir, Je me pose une question sur le "coût" en terme de rapidité des appels "en cascade".
Vous avez par exemple une variable a.b.c.d qui représente un type X* possédant une fonction FaireQuelqueChose(int)
Vous feriez : A/ for(int i=0;i<100000;++i) a.b.c.d->FaireQuelqueChose(i); ou B/ X *ptr=a.b.c.d; for(int i=0;i<100000;++i) ptr->FaireQuelqueChose(i);
Il ne faut pas chercher de sens à l'exemple, c'est juste pour illustrer mon propos. Personnellement, s'il y a beaucoup d'itérations, je choisirais la seconde solution. Et vous ? Marc
Un "bon" compilateur avec les options adéquates va sortir l'évaluation de l'adresse de la boucle. En clair, il va faire en A/ ce que tu fais en B/. Il faut donc faire des essais avec ton compilateur.
MGN a écrit :
Bonsoir,
Je me pose une question sur le "coût" en terme de rapidité des appels
"en cascade".
Vous avez par exemple une variable
a.b.c.d
qui représente un type X* possédant une fonction FaireQuelqueChose(int)
Vous feriez :
A/
for(int i=0;i<100000;++i)
a.b.c.d->FaireQuelqueChose(i);
ou
B/
X *ptr=a.b.c.d;
for(int i=0;i<100000;++i)
ptr->FaireQuelqueChose(i);
Il ne faut pas chercher de sens à l'exemple, c'est juste pour illustrer
mon propos.
Personnellement, s'il y a beaucoup d'itérations, je choisirais la
seconde solution.
Et vous ?
Marc
Un "bon" compilateur avec les options adéquates va sortir l'évaluation
de l'adresse de la boucle. En clair, il va faire en A/ ce que tu fais en B/.
Il faut donc faire des essais avec ton compilateur.
Bonsoir, Je me pose une question sur le "coût" en terme de rapidité des appels "en cascade".
Vous avez par exemple une variable a.b.c.d qui représente un type X* possédant une fonction FaireQuelqueChose(int)
Vous feriez : A/ for(int i=0;i<100000;++i) a.b.c.d->FaireQuelqueChose(i); ou B/ X *ptr=a.b.c.d; for(int i=0;i<100000;++i) ptr->FaireQuelqueChose(i);
Il ne faut pas chercher de sens à l'exemple, c'est juste pour illustrer mon propos. Personnellement, s'il y a beaucoup d'itérations, je choisirais la seconde solution. Et vous ? Marc
Un "bon" compilateur avec les options adéquates va sortir l'évaluation de l'adresse de la boucle. En clair, il va faire en A/ ce que tu fais en B/. Il faut donc faire des essais avec ton compilateur.
James Kanze
On Sep 20, 9:14 am, Wykaaa wrote:
MGN a écrit :
> Je me pose une question sur le "coût" en terme de rapidité > des appels "en cascade".
> Vous avez par exemple une variable > a.b.c.d
Juste un détail, mais ce n'est pas une variable, mais une expression.
> qui représente un type X* possédant une fonction > FaireQuelqueChose(int)
> Il ne faut pas chercher de sens à l'exemple, c'est juste > pour illustrer mon propos. Personnellement, s'il y a > beaucoup d'itérations, je choisirais la seconde solution Et > vous ?
Tant que le profiler ne me dit pas autrement, je choisirais celui qui est le plus lisible et le plus clair pour le lecteur. Ce qui dépend du contexte ; le deuxième accentue le fait que la fonction est toujours appelée sur le même objet. En revanche, s'il est permis que FaireQuelqueChose modifie l'état du programme d'une façon qui pourrait modifier la valeur de rétour d'une des autres fonctions (actuellement, ou potentiellement, dans une version future -- c-à-d si le contrat de la fonction ne l'empèche pas), alors, la version B n'est même pas correcte.
Un "bon" compilateur avec les options adéquates va sortir l'évaluation de l'adresse de la boucle.
Un très bon compilateur. Pour ce faire, il faut que le compilateur puisse voir dans toutes les fonctions concernées, et bien déterminer que la valeur renvoyée est invariante. Certains compilateurs en sont capables, même si les fonctions se trouvent dans d'autres unités de compilation, mais ils ne sont pas courants.
-- James Kanze
On Sep 20, 9:14 am, Wykaaa <wyk...@yahoo.fr> wrote:
MGN a écrit :
> Je me pose une question sur le "coût" en terme de rapidité
> des appels "en cascade".
> Vous avez par exemple une variable
> a.b.c.d
Juste un détail, mais ce n'est pas une variable, mais une
expression.
> qui représente un type X* possédant une fonction
> FaireQuelqueChose(int)
> Il ne faut pas chercher de sens à l'exemple, c'est juste
> pour illustrer mon propos. Personnellement, s'il y a
> beaucoup d'itérations, je choisirais la seconde solution Et
> vous ?
Tant que le profiler ne me dit pas autrement, je choisirais celui
qui est le plus lisible et le plus clair pour le lecteur. Ce qui
dépend du contexte ; le deuxième accentue le fait que la
fonction est toujours appelée sur le même objet. En revanche,
s'il est permis que FaireQuelqueChose modifie l'état du
programme d'une façon qui pourrait modifier la valeur de rétour
d'une des autres fonctions (actuellement, ou potentiellement,
dans une version future -- c-à-d si le contrat de la fonction ne
l'empèche pas), alors, la version B n'est même pas correcte.
Un "bon" compilateur avec les options adéquates va sortir
l'évaluation de l'adresse de la boucle.
Un très bon compilateur. Pour ce faire, il faut que le
compilateur puisse voir dans toutes les fonctions concernées, et
bien déterminer que la valeur renvoyée est invariante. Certains
compilateurs en sont capables, même si les fonctions se trouvent
dans d'autres unités de compilation, mais ils ne sont pas
courants.
> Il ne faut pas chercher de sens à l'exemple, c'est juste > pour illustrer mon propos. Personnellement, s'il y a > beaucoup d'itérations, je choisirais la seconde solution Et > vous ?
Tant que le profiler ne me dit pas autrement, je choisirais celui qui est le plus lisible et le plus clair pour le lecteur. Ce qui dépend du contexte ; le deuxième accentue le fait que la fonction est toujours appelée sur le même objet. En revanche, s'il est permis que FaireQuelqueChose modifie l'état du programme d'une façon qui pourrait modifier la valeur de rétour d'une des autres fonctions (actuellement, ou potentiellement, dans une version future -- c-à-d si le contrat de la fonction ne l'empèche pas), alors, la version B n'est même pas correcte.
Un "bon" compilateur avec les options adéquates va sortir l'évaluation de l'adresse de la boucle.
Un très bon compilateur. Pour ce faire, il faut que le compilateur puisse voir dans toutes les fonctions concernées, et bien déterminer que la valeur renvoyée est invariante. Certains compilateurs en sont capables, même si les fonctions se trouvent dans d'autres unités de compilation, mais ils ne sont pas courants.
-- James Kanze
MGN
> Le plus simple est de mesurer le temps d'exécution. Et si tu ne vois aucune différence mesurable, ce n'est pas forcément par hasard.
oui, la différence n'est pas évidente... Merci pour ta réponse
> Le plus simple est de mesurer le temps d'exécution. Et si tu ne vois
aucune différence mesurable, ce n'est pas forcément par hasard.
oui, la différence n'est pas évidente...
Merci pour ta réponse
> Le plus simple est de mesurer le temps d'exécution. Et si tu ne vois aucune différence mesurable, ce n'est pas forcément par hasard.
oui, la différence n'est pas évidente... Merci pour ta réponse
MGN
> Tant que le profiler ne me dit pas autrement, je choisirais celui qui est le plus lisible et le plus clair pour le lecteur.
ça compte aussi bien sûr. Comme tout le monde il m'arrive de faire des petites macros locales à cette fin. Merci pour réponse. Je vais retenir ce principe ! Marc
> Tant que le profiler ne me dit pas autrement, je choisirais celui
qui est le plus lisible et le plus clair pour le lecteur.
ça compte aussi bien sûr. Comme tout le monde il m'arrive de faire des
petites macros locales à cette fin.
Merci pour réponse. Je vais retenir ce principe !
Marc
> Tant que le profiler ne me dit pas autrement, je choisirais celui qui est le plus lisible et le plus clair pour le lecteur.
ça compte aussi bien sûr. Comme tout le monde il m'arrive de faire des petites macros locales à cette fin. Merci pour réponse. Je vais retenir ce principe ! Marc
