Discussion :

[vladvad]

Ces 2 morceaux de code réalisent la même opération mais lequel est le plus rapide ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
int m;
for (int n = 0; n < 10000; n++)
{
    m = n + 1;
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
for (int n = 0; n < 10000; n++)
{
     int m = n + 1;
}

Je serais tenté de dire qu'une fois compilé c'est pareil ...

[Thomas Lebrun]

Dans le 1er cas, tu ne fais que de la réafectation de valeur à une variable.

Dasn le deuxième cas, tu recréés autant de variables locale que tu passes dans la boucle.

En terme de rapidité, je ne sais pas mais en terme de performances, je dirais que la 1ere est la mieux....

[Chubyone]

Le résultat est le meme, certes...

Mais dans le second cas tu redéclare a chaque fois un objet Int32.

Et qu'est ce qu'il fait a la fin de l'itération de la boucle? il est perdu => gogo bourrage dans le Garbage collector...

Essaye de créer 30 gros objet dans ta boucle, puis mate les ressources mémoire de ton appli: tu verra sa consommation mémoire montée descendre.... (c'est pas flagrant avec tes int, ok... C'est flagrant quand tu suis certains conseil dans gdi+ qui recréer un Graphics a chaque paint...)

Dans le premier cas, tu alloues, tu modifies, modifies, modifies...
Dans le second cas, tu alloues, tu modifies, tu jetes a la corbeille, tu alloues, tu modifies, tu jetes, tu...
Ca saute aux yeux

Bref, c'est pas cool.. Evidemment ca ne change pas grand chose avec des Int32, mais inutile de donner plus de boulot que nécessaire au GC : vider le GC est un process assez long, autant bien codé des le début et éviter de surallouer comme un bourrin...

Non, je n'ai pas dit non plus de tout mettre en membre La tu gonfles ta mémoire inutilement...


Je crois meme que :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
m = n + 1; (=> m = n++; )

va déclarer une variable intermédiaire = à 1 pour effectuer l'opération (comme pour n++)
si tu fais

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
m = ++n;

il sauteras cette étape.

(bon c'est beaucoup de "on dit", j'ai jamais pris le temps de vérifier personnellement coté assembleur...)

[Keihilin]

Le premier morceau de code est une bonne pratique, le second est une erreur qui peut s'avérer fatale pour les performances...

...du moins en théorie car il me semble que c'est un cas détecté et corrigé par le compilateur.

A vérifier, mais ces deux codes devraient donner exactement le même IL, avec l'allocation hors de la boucle.

[Maniak]

Aucun impact de perfs dans ce cas-là. C'est un int, une structure, allouée sur la pile. Le GC n'entre pas du tout en jeu.

Après, erreur ou pas, ça dépend du reste du code. Là de toute façon aucune des deux versions ne sert à quoi que ce soit (ok, la 2è est encore moins utile :)

Si on prend ça et qu'on sort la version assembleur avec le débuggueur, la variable m est un bête registre. Pas besoin de plus. C'est pas ça qui va faire la moindre différence de perf...

[vladvad]

Je serais aussi tenté de dire que le compilateur corrige automatiquement la deuxième version ...

Sinon, il y aurait une erreur du style : "la variable m existe déjà ..."

Je ne vois pas non plus comment le GC aurait le temps d'intervenir vu la rapidité de la boucle ...

PS : je sais bien que ce code n'a aucun intérêt, c'est juste un exemple

[sayag]

apres avoir testé c, cpp, fortran, vb, cs, java...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

for (int n = 0; n < 10000; n++) {  int m = n + 1; }

me semble fort malsain

[SaumonAgile]

me semble fort malsain

Merci de cette remarque on ne peut plus constructive et argumentée...

[Maniak]

Je serais aussi tenté de dire que le compilateur corrige automatiquement la deuxième version ...

Pas trop non.

Sinon, il y aurait une erreur du style : "la variable m existe déjà ..."

Si tu mets les deux boucles dans la même méthode oui. Sinon il n'y a pas d'erreur. C'est juste que les deux boucles ne font pas la même chose.

Je ne vois pas non plus comment le GC aurait le temps d'intervenir vu la rapidité de la boucle ...

Le GC n'intervient pas, ça ne traite que des entiers

PS : je sais bien que ce code n'a aucun intérêt, c'est juste un exemple ;)

Bah faudrait un exemple un poil plus compliqué parce que là il commence à y avoir pas mal de monde qui se prend la tête pour rien dessus :)

Déjà avec des entiers, pas d'allocation donc rien à signaler. Ensuite si c'était avec des classes donc que le nombre d'allocations pourrait devenir conséquent... est-ce que dans du vrai code d'une vraie appli, tu as souvent des boucles de dizaines de milliers d'itérations qui créent sans arrêt les mêmes objets et qui posent des problèmes de perfs à cause de ça ?

Parce qu'au risque de répéter ce que j'ai déjà dû dire en boucle des dizaines de milliers d'itérations par ici, les arrachages de cheveux pour optimiser les perfs et grapiller quelques cycles, ça vient *après*, *si* tu as des problèmes de perfs. Avant ça, la clarté/simplicité/maintenabilité du code a priorité. Donc notamment variables déclarées avec la portée la plus réduite possible, donc instances créées à l'intérieur des boucles tant qu'elles n'ont pas à exister en dehors. Qu'on laisse le GC s'occuper de faire son job. On a toujours moyen de lui filer un coup de main dans les *rares* cas où il aurait vraiment du mal...