[C++] Question rapide...Parcours de boucle...Quel est le plus rapide?

Question rapide...Parcours de boucle...Quel est le plus rapide? [C++] - C++ - Programmation

Marsh Posté le 10-08-2004 à 11:46:11    

Salut,
 
Je me posais une questions.
 
Sachant que la variable tabTemp est du type CObArray (par exemple), vaut il mieux faire:
 

Code :
  1. int n=tabTemp.GetSize();
  2. for (int i=0; i<n;i++){
  3. ...
  4. }


 
ou alors:
 

Code :
  1. for (int i=0; i<tabTemp.GetSize();i++){
  2. ...
  3. }


 
Car je me demande si le compilateur va calculer le GetSize() a chaque passage ou pas?
 
Merci.


Message édité par Yoyo@ le 10-08-2004 à 14:49:41
Reply

Marsh Posté le 10-08-2004 à 11:46:11   

Reply

Marsh Posté le 10-08-2004 à 11:58:38    

Et si la taille est modifiée dans la boucle?

Reply

Marsh Posté le 10-08-2004 à 11:59:18    

ça dépend si cette classe est programmée avec les pieds ou pas. si elle est bien faite, GetSize() sera inliné et sous réserve que GetSize() ressemble à { return this->size; } ça sera strictement équivalent

Reply

Marsh Posté le 10-08-2004 à 11:59:28    

titre à la con [:ban]

Reply

Marsh Posté le 10-08-2004 à 12:42:52    

Taz a écrit :

titre à la con [:ban]


 
Bah donne moi un titre convenable, et je le modifie sur le champ. Je nai pas trouvé mieux comme titre...

Reply

Marsh Posté le 10-08-2004 à 12:43:55    

j'ai fais le test avec un vector, c'est meme  plus rapide (en -O3), c'est normal ?

Reply

Marsh Posté le 10-08-2004 à 12:44:26    

Taz a écrit :

ça dépend si cette classe est programmée avec les pieds ou pas. si elle est bien faite, GetSize() sera inliné et sous réserve que GetSize() ressemble à { return this->size; } ça sera strictement équivalent


 
Bah imaginons que lon prenne la classe CObArray? Je ne sais pas si l'accesseur est inliné... On ne pt pas le savoir a priori?
 
Mais meme s'il était inliné, n'est ce pas mieux de mettre directement la taille de l'objet dans une variable entiere avant la boucle? (sachant que je sais que la taille ne sera pas modifiée?)

Reply

Marsh Posté le 10-08-2004 à 12:46:30    

bien sur que si, si c'est inline, c'est forcement dans le header de la classe, soit dans le corps, soit à l'exterieur en explicite inline

Reply

Marsh Posté le 10-08-2004 à 12:50:22    

Si c'est dans le corps de la classe, est ce que c'est indiqué dans le header?

Reply

Marsh Posté le 10-08-2004 à 12:52:39    

oui, quand je  parle de corps (je crois pas que ce soit le bon mot), je veux dire dans  
 
...
class ...
{
...
};

Reply

Marsh Posté le 10-08-2004 à 12:52:39   

Reply

Marsh Posté le 10-08-2004 à 13:16:30    

non les 2 versions sont pas pareille. La 2eme sera réevaluer a chaque tour de boucle alors que la 1ere non.
 
Et le fait d'avoir une fonction inliné n'a rien a voir avec le probleme

Reply

Marsh Posté le 10-08-2004 à 13:23:38    

c tout simple pour verifier :  
decompilation sous win32dasm et tu sera fixé

Reply

Marsh Posté le 10-08-2004 à 13:23:39    

Crimy a écrit :

non les 2 versions sont pas pareille. La 2eme sera réevaluer a chaque tour de boucle alors que la 1ere non.
 
Et le fait d'avoir une fonction inliné n'a rien a voir avec le probleme


 
Bah quand meme, quand je fais : i<n ou i<tabTemp.GetSize(), si le GetSize() est inliné, je peux imaginer qu'il s'agit simplement de l'acces a une variable mémoire tout comme ca le serait avec n, donc, c'est pareil, nan?

Reply

Marsh Posté le 10-08-2004 à 13:25:00    

red faction a écrit :

c tout simple pour verifier :  
decompilation sous win32dasm et tu sera fixé


 
a ce moment la c'est encore plus simple de sortir dircetement le listing asm du compilo

Reply

Marsh Posté le 10-08-2004 à 13:26:42    

Crimy a écrit :

non les 2 versions sont pas pareille. La 2eme sera réevaluer a chaque tour de boucle alors que la 1ere non.
 
Et le fait d'avoir une fonction inliné n'a rien a voir avec le probleme


 
le mieux  c'est de faire le test (avec les optionsd'optimisation du compilo) et de regarder listing asm su programme

Reply

Marsh Posté le 10-08-2004 à 13:33:56    

Yoyo@ a écrit :

Bah quand meme, quand je fais : i<n ou i<tabTemp.GetSize(), si le GetSize() est inliné, je peux imaginer qu'il s'agit simplement de l'acces a une variable mémoire tout comme ca le serait avec n, donc, c'est pareil, nan?


 
dans l'absolu, le getsize peut etre une fonction + complexe que simplement lire une variable (si c une classe qui a des data dynamique, le getsize fait ptet tout en algo pour calculer la taille). Si ca lis juste une variable oui, on va dire que c pareil.

Reply

Marsh Posté le 10-08-2004 à 13:39:59    

Crimy a écrit :

si c une classe qui a des data dynamique, le getsize fait ptet tout en algo pour calculer la taille


 
tes sur ? ca serait pas plutot la taille qui est mise à jours quand c'est necessaire ?

Reply

Marsh Posté le 10-08-2004 à 14:09:57    

bah tant que ta pas vu comment est codé le GetSize() t sur de rien. Ca fait ptet des appels reseau, des appels disques bref nimporte quoi est envisageable.


Message édité par Crimy le 10-08-2004 à 14:11:28
Reply

Marsh Posté le 10-08-2004 à 14:11:20    

oui, c'est pour ca que
 

cris56 a écrit :

le mieux  c'est de faire le test (avec les optionsd'optimisation du compilo) et de regarder listing asm su programme

Reply

Marsh Posté le 10-08-2004 à 14:19:59    

Si Harko passait ici, il dirait de faire la boucle du dernier élément au premier élément :o


---------------
Whichever format the fan may want to listen is fine with us – vinyl, wax cylinders, shellac, 8-track, iPod, cloud storage, cranial implants – just as long as it’s loud and rockin' (Billy Gibbons, ZZ Top)
Reply

Marsh Posté le 10-08-2004 à 14:22:34    

Yoyo@ a écrit :

Bah donne moi un titre convenable, et je le modifie sur le champ. Je nai pas trouvé mieux comme titre...


Ton titre laisse penser que t'es en train de troller sur une comparaison de performances entre le C++ et le VC++, ce qui ne veut rien dire, car C++ n'est qu'un langage et pas une implémentation de ce langage.
 
Donc vire le "C++/" du titre.

Reply

Marsh Posté le 10-08-2004 à 14:25:07    

De toutes facons, si t'es sur que la taille est constante, quel est l'inconvénient d'utiliser une variable n supplémentaire?


Message édité par Ace17 le 10-08-2004 à 14:25:50
Reply

Marsh Posté le 10-08-2004 à 14:27:56    

j'ai fais le test  avec le parcours d'un vector, il semble  que ce soit 10% plus rapide
 
edit : mais c'etait juste un simple parcours, avec plus d'instructions dans  la boucle, la difference devient negligeable


Message édité par cris56 le 10-08-2004 à 14:29:46
Reply

Marsh Posté le 10-08-2004 à 14:34:26    

drasche a écrit :

Si Harko passait ici, il dirait de faire la boucle du dernier élément au premier élément :o


 
 
tu parles, il faut mieux acceder a un tableau dans un ordre d'indice croissant

Reply

Marsh Posté le 10-08-2004 à 14:51:05    

Ace17 a écrit :

De toutes facons, si t'es sur que la taille est constante, quel est l'inconvénient d'utiliser une variable n supplémentaire?


 
Bah quasiment aucun inconvénient, i ce nestque ca utilise une entier supplémentaire, une allocation supplémentaire, et que le source est plus lourd.
 
Bien sur, ca ne changera strictement rien dans mon programme final, mais je me posais la question...

Reply

Marsh Posté le 14-08-2004 à 14:31:32    

Comment faire parler 10 personnes... :)
pr repondre a yoyo : utilise une variable contenant la taille, ca fait un saut de fonction (sauf si inline) en moins a chaque tour de boucle.
en + si c inline ben ton code serait+ gros donc tu vois t as vraiment aucun interet a utiliser la methode a chaque tour de boucle.
d autant + que tu sais ke la taille varie pas.
 
encore + class : utilise ta variable declarée comme suit :  
 
register int n=0;
 
mais bon a la limite je pense qu'avec un compilo évolué la mise en registre se fait toute seule

Reply

Marsh Posté le 14-08-2004 à 16:14:18    

oui, register c'est depassé

Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed