Differences entre foreach et enumerator

Version imprimable

Bonjour,

J'aimerai savoir si qulequ'un connait la difference entre un foreach et un enumerator. Afin de parcourir des collections, j'utilise 2 genres de methodes:
Code:

1 2 3 4 5 6 7 8 9 IEnumerator EnumDataRows = this.dS_Parameter.T_PARAMETER.Rows.GetEnumerator(); while (EnumDataRows.MoveNext()) { LMA_DataSets.DS_Parameter.T_PARAMETERRow MyRow = (LMA_DataSets.DS_Parameter.T_PARAMETERRow)EnumDataRows.Current; MessageBox.Show(MyRow.PARAMETER_NAME); }
Ou alors:
Code:

1 2 3 4 5 6 7 8 foreach (DataGridViewRow MyRow in this.dgv_Parameters.Rows) { if (MyRow.IsNewRow == false) { CurrentSeqNo++; RowsToRenumber.Add(MyRow.Cells["PARAMETER_ID"].Value, CurrentSeqNo); } }
Quelle est la meilleure solution en termes de rapidite et de securite selon vous ?

04/12/2007, 09h00
Bluedeep

L'énumérateur te permet de faire des choses un peu casse-pieds à programmer avec le foreach; par exemple examiner une n-ième valeur et en fonction de celle ci déterminer quel comportement devra avoir ta routine avec la n+1-ième, puis lire la n+1-ième.

Mais les deux bouts de code que tu postes sont équivalent. A priori, je pense que le foreach est peut être un chouia plus performant, mais je ne me suis jamais posé la question en ces termes, plutôt dans le sens inverse : je ne peux pas - ou difficilement- faire avec foreach, ergo je fais avec Enumerator.
04/12/2007, 09h43
Kaidan

A mon avis, il faut un IEnumerator pour utiliser foreach.

En effet, lorsqu'on crée une classe collection de A à Z et pour pouvoir utiliser foreach, il faut que la classe implémente IEnumerable qui nécessite l'implémentation de IEnumerator GetEnumerator().
04/12/2007, 09h44
Bluedeep

Citation:

Envoyé par Kaidan

A mon avis, il faut un IEnumerator pour utiliser foreach.

Il est clair qu'en interne, c'est ce qu'il utilise; mais de là à dire que c'est plus performant de l'appeler explicitement, je ne sais pas.
04/12/2007, 09h46
Kaidan

Il suffirait de regarder le MSIL, mais à mon avis, le compilateur traduit foreach en while.
04/12/2007, 11h02
Contrec

Donc le foreach utilise l'enumerator implicitement...

Conclusion ?
04/12/2007, 11h06
Kaidan

Conclusion, tu utilises un Stopwatch pour mesurer le temps que prend 100000 itérations de ton code et tu regardes lequel est plus rapide :roll:

Mais à mon avis, c'est quasi-identique.
04/12/2007, 11h14
Chubyone

Citation:

Envoyé par Contrec

Conclusion ?

Ca dépend du besoin :
si tu va appliquer un traitement à tous donc (pour chaque..) autant utiliser un foreach qui est clair et compris par tous à la premiere lecture...

Si tu as besoin de parcourir la collection pour t'arreter à l'une d'elle / certaines spécifiquement, ou cycliquement, tu ne peux que la parcourir toi meme...

Pour la différence de perf, je doute qu'il y ai une véritable différence, puisque derriere un foreach il utilisera l'enum de la même façon...
Ce n'est pas le parcourt d'une collection qui pénalisera les perfs, mais l'algo que tu appliqueras à ceux qui t'intéressent....

Enfin bref, je pense qu'il est plus important de bien choisir sa collection en fonction de son besoin, plutôt que de se demander si son parcourt sera plus rapide de cette façon là ou de l'autre... :)
04/12/2007, 11h32
Guulh

Citation:

Envoyé par Chubyone

Ca dépend du besoin :
si tu va appliquer un traitement à tous donc (pour chaque..) autant utiliser un foreach qui est clair et compris par tous à la premiere lecture...

Si tu as besoin de parcourir la collection pour t'arreter à l'une d'elle / certaines spécifiquement, ou cycliquement, tu ne peux que la parcourir toi meme...

Bah ? je croyais que break fonctionnait aussi avec foreach ? :mrgreen:

De mon point de vue, l'intérêt principal du foreach, c'est qu'il encapsule des comportements différents en fonction du type de collection derrière une syntaxe simple et unique. On peut faire un foreach sur un int[], sur un List<int>, sur un IEnumerable<int> avec un truc à base de yield return ; on peut ignorer la machinerie interne à la collection, comme les itérateurs c++. Même le c++, qui malgré tout le respect que j'ai pour lui est pas des plus accessibles, a essayé d'uniformiser le parcours des ensembles par une syntaxe à peu près unique.

foreach, c'est bien :) Même s'il doit arriver ponctuellement que ça soit plus rapide de faire un MoveNext à la mano.
04/12/2007, 11h44
maitredede

Le foreach, c'est bien.

Après, j'ai lu un article ya pas si longtemps qui comparait les performances entre un foreach, et une boucle type for(int i=0;i<count;i++).
Le foreach est beaucoup plus lent que le for.

Perso, les perfs, c'est bien d'y penser, mais si il faut modifier tout un programme pour gagner un pouillème, ça sert à rien. Mon avis, c'est que chacun fait comme il le sent, puisqu'on a le choix.
04/12/2007, 11h49
Chubyone

Right pour le break, comme le return, yield return, etc...

La puissance du foreach, c'est qu'il s'appuie sur IEnumerable...
Et justement, int[] = System.Array, lui meme hérite de IEnumerable... ;)

C'est vraiment puissant .Net!....

Donc bon, si tu veux vraiment des perfs de ouf, bein tu peux faire un tableau de pointeurs en compilant en unsafe, et le parcourir en downto0... Je pense que là tu sera plus rapide... :mouarf:
04/12/2007, 11h59
Guulh

Citation:

Envoyé par Chubyone

Right pour le break, comme le return, yield return, etc...

La puissance du foreach, c'est qu'il s'appuie sur IEnumerable...
Et justement, int[] = System.Array, lui meme hérite de IEnumerable... ;)

C'est vraiment puissant .Net!....

C'est même plus puissant que ça : foreach ne traite pas tous les énumerables de la même façon, comme montré ici pour les machin[] : http://www.csharphelp.com/archives4/archive690.html
Reste à savoir si cette optimisation est aussi vraie quand un int[] est connu du foreach seulement en tant que IEnumerable<int>.

Et pour les perfs :
http://blogs.msdn.com/kevin_ransom/a...19/116072.aspx
sur un machin[], for et foreach génèrent le même code IL.
04/12/2007, 12h16
Chubyone

Merci pour la lecture :D

Bon, plus personne ici ne doutera du bienfait de notre ami foreach maintenant, je pense...

Enfin, on attend toujours tes tests de perf entre les deux, Contrec :P
04/12/2007, 13h00
Guulh

Après quelques lecture sur le web, il ressort tout de même que faire foreach sur un IEnumerable qui ne peut être déterminé statiquement comme un machin[] passe par l'énumérateur, en faisant un try {} catch {} pour l'acquérir. Dans certains scénarios où le coût d'un try est prohibitif, on pourrait donc préférer MoveNext, mais la plupart du temps on s'en fiche :)

salut

j'ai fait le test suivant :

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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
private void button1_Click(object sender, EventArgs e)
        {
            ml.Clear();
 
            for (int i = 0; i < 1000000; i++)
            {
                Toto item = new Toto();
                item.Name = "nico_" + i.ToString();
                item.Age = 2;
                ml.Add(item);
            }
 
            string a = string.Empty;
            long res = 0;
            Stopwatch watch = new Stopwatch();
            watch.Start();
            foreach (Toto t in ml)
            {
                res += t.Age;
            }
 
            watch.Stop();
            Trace.WriteLine("elapsed with Foreach = " + watch.Elapsed.ToString());
            watch.Reset();
            res = 0;
            watch.Start();
 
            int count = ml.Count;
 
            for (int i = 0; i < count; i++)
            {
                res += ml[i].Age;
            }
 
            watch.Stop();
            Trace.WriteLine("elapsed with For= " + watch.Elapsed.ToString());
 
            watch.Reset();
            res = 0;
            watch.Start();
 
            IEnumerator ie = ml.GetEnumerator();
            while (ie.MoveNext())
            {
                res+= ((Toto)ie.Current).Age;
            }
 
            watch.Stop();
            Trace.WriteLine("elapsed with IEnumerator = " + watch.Elapsed.ToString());
 
        }

ou Toto est defini comme

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
public struct Toto
    {
        private string name;
        private int age;
 
        public int Age
        {
            get { return age; }
            set { age = value; }
        }
 
        public string Name
        {
            get { return name; }
            set { name = value; }
        }
 
    }

Voici les resultats sur ma machine en Release :

Portable HP : Proc 1.73 Ghz Ram 1 Go

elapsed with Foreach = 00:00:00.0486056
elapsed with For= 00:00:00.0396902
elapsed with IEnumerator = 00:00:00.2896264

On constate "clairement" :) que le For est un peu plus rapide... Par contre,
l'énumération (sur une itération de 1000000 d'élément, ca rame sec :)

Voila...

The Monz, Toulouse

04/12/2007, 13h49
theMonz31

Re

J'ajouterais que dans le ForEach, on ne peut pas "affecter" et modifier
la valeure en cours...

Alors, que dans un For on peut très bien le faire :)

Genre

for(int i = 0 ; i < ....)
{
malist[i] = new object(....);
}

The Monz, Toulouse
04/12/2007, 13h54
Guulh

Il est normal que ta version avec énumérateur soit lente, puisque tu es obligé de caster. De plus, ta liste contient une struct ; le compilo est obligé de boxer / déboxer :) Tu devrais réessayer avec des class au lieu de structs, ou bien voir si on peut récupérer un énumérateur typé (pas vérifié, mais ça doit être possible)
04/12/2007, 13h57
theMonz31

salut

elapsed with Foreach = 00:00:00.0423824
elapsed with For= 00:00:00.0388499
elapsed with IEnumerator = 00:00:00.0613480

en mettant une classe à la place d'une struct :)

The Monz, Toulouse
04/12/2007, 14h07
Contrec

Niquel, je pensais que c'etatit l'enumerator qui allait plus vite...
04/12/2007, 14h53
npuzin

Citation:

Envoyé par maitredede

Le foreach, c'est bien.
Perso, les perfs, c'est bien d'y penser, mais si il faut modifier tout un programme pour gagner un pouillème, ça sert à rien. Mon avis, c'est que chacun fait comme il le sent, puisqu'on a le choix.

Effectivement je pense que ce genre d'optimisation est d'un autre temps. La où généralement tu peux gagner un temps significatif avec des optimisations ce sont sur les accès disques éventuellement mais surtout sur les accès réseaux (genre requêtes HTTP ou SQL).

Si tu as un ping de 0.33s entre ton client et ton serveur tu fais 3 requetes et tu as deja un temps de reponse d'une seconde. Ton pouilleme sera le cadet de tes soucis.

Pour moi le foreach est un raccourci de langage sur l'autre syntaxe. Je ne vois pas vraiment d'intérêt à utiliser l'autre syntaxe.
04/12/2007, 14h56
theMonz31

salut

pour moi, le seul interet du For par rappor au foreach est la possibilité
de pouvoir modifier l'objet dans ta boucle for (en le reaffectant (avec constructeur etc...) car dans un foreach, tu ne peux pas modifier
l'objet)

The Monz, Toulouse
04/12/2007, 15h17
ced600

En même temps c'est très dangereux de réaffecter l'objet.

Bah ce qui est dangereux est de réaffecter la propriété qui sert à déterminer la fin de la boucle for :D

Cela me rappelle mes premiers pas en programmation et les boucles infinis que j'obtenais car je m'amusé avec la valeur de test du compteur car au final je l'incrémentais en même tempq que le compteur sans faire exprès suite à une mauvaise programmation :mrgreen:
04/12/2007, 16h41
BigNic

Citation:

Envoyé par npuzin

Effectivement je pense que ce genre d'optimisation est d'un autre temps. La où généralement tu peux gagner un temps significatif avec des optimisations ce sont sur les accès disques éventuellement mais surtout sur les accès réseaux (genre requêtes HTTP ou SQL).

Si tu as un ping de 0.33s entre ton client et ton serveur tu fais 3 requetes et tu as deja un temps de reponse d'une seconde. Ton pouilleme sera le cadet de tes soucis.

Pour moi le foreach est un raccourci de langage sur l'autre syntaxe. Je ne vois pas vraiment d'intérêt à utiliser l'autre syntaxe.

Personnellement dans mon ancienne boite, j'ai pas mal bossé sur les problème de perf et ce que j'en retire c'est qu'il n'y a pas de vérité absolue. Les requêtes HTTP et autes ecritures socket ne ralentisse pas forcément plus qu'un algo mal gaulé ou une boucle mal foutue. Quand à ceux qui code performant et pondent du code imbitable, je les conchie. Cela n'engage que moi, mais je pense qu'il vaut mieux coder de façon à bien montrer les intentions de son code. Puis après, à l'aide d'outils ou non, voir ce qui coute en perf réellement en situation de prod et travailler uniquement la dessus.
04/12/2007, 16h45
ced600

+1

La vérité sort de ta bouche :ave:
04/12/2007, 17h08
npuzin

Citation:

Quand à ceux qui code performant et pondent du code imbitable, je les conchie. Cela n'engage que moi, mais je pense qu'il vaut mieux coder de façon à bien montrer les intentions de son code.

J'approuve.

J'ajouterais même qu'anticiper les problèmes c'est bien, ajouter des problèmes là où il n'y en a pas, c'est une perte de temps pour toi et pas sympa pour tes collègues.
05/12/2007, 11h07
ced600

Citation:

ajouter des problèmes là où il n'y en a pas

Surtout c'est qu'ajouter des problèmes à version stable c'est vraiment domageable, car on ne sait pas quand est ce que l'on arrivera à en retrouver une :mouarf:

C'est pour cela qu'il faut faire du versionning, mais là je dérive :D
07/12/2007, 08h35
Contrec

Bon merci pour toutes ces reponses. Je clos le sujet.

Merci a tous pour vos points de vue tres interessants.