Différence de performances pour les structures de contrôle «for» et «foreach» en C #

Quel extrait de code offrira de meilleures performances? Les segments de code ci-dessous ont été écrits en C #.

1.

for(int counter=0; counter<list.Count; counter++)
{
    list[counter].DoSomething();
}

2.

foreach(MyType current in list)
{
    current.DoSomething();
}

Eh bien, cela dépend en partie du type exact de list. Cela dépendra également du CLR exact que vous utilisez.

Que ce soit significatif ou non dépendra du fait que vous effectuez un vrai travail en boucle. Dans presque tous les cas, la différence de performance ne sera pas significative, mais la différence de lisibilité favorise la foreachboucle.

J'utiliserais personnellement LINQ pour éviter aussi le "si":

foreach (var item in list.Where(condition))
{
}

EDIT: Pour ceux d'entre vous qui prétendent que l'itération sur un List<T>avec foreachproduit le même code que la forboucle, voici la preuve que ce n'est pas le cas:

static void IterateOverList(List<object> list)
{
    foreach (object o in list)
    {
        Console.WriteLine(o);
    }
}

Produit IL de:

.method private hidebysig static void  IterateOverList(class [mscorlib]System.Collections.Generic.List`1<object> list) cil managed
{
  // Code size       49 (0x31)
  .maxstack  1
  .locals init (object V_0,
           valuetype [mscorlib]System.Collections.Generic.List`1/Enumerator<object> V_1)
  IL_0000:  ldarg.0
  IL_0001:  callvirt   instance valuetype [mscorlib]System.Collections.Generic.List`1/Enumerator<!0> class [mscorlib]System.Collections.Generic.List`1<object>::GetEnumerator()
  IL_0006:  stloc.1
  .try
  {
    IL_0007:  br.s       IL_0017
    IL_0009:  ldloca.s   V_1
    IL_000b:  call       instance !0 valuetype [mscorlib]System.Collections.Generic.List`1/Enumerator<object>::get_Current()
    IL_0010:  stloc.0
    IL_0011:  ldloc.0
    IL_0012:  call       void [mscorlib]System.Console::WriteLine(object)
    IL_0017:  ldloca.s   V_1
    IL_0019:  call       instance bool valuetype [mscorlib]System.Collections.Generic.List`1/Enumerator<object>::MoveNext()
    IL_001e:  brtrue.s   IL_0009
    IL_0020:  leave.s    IL_0030
  }  // end .try
  finally
  {
    IL_0022:  ldloca.s   V_1
    IL_0024:  constrained. valuetype [mscorlib]System.Collections.Generic.List`1/Enumerator<object>
    IL_002a:  callvirt   instance void [mscorlib]System.IDisposable::Dispose()
    IL_002f:  endfinally
  }  // end handler
  IL_0030:  ret
} // end of method Test::IterateOverList

Le compilateur traite les tableaux différemment, convertissant une foreachboucle en une forboucle, mais pas List<T>. Voici le code équivalent pour un tableau:

static void IterateOverArray(object[] array)
{
    foreach (object o in array)
    {
        Console.WriteLine(o);
    }
}

// Compiles into...

.method private hidebysig static void  IterateOverArray(object[] 'array') cil managed
{
  // Code size       27 (0x1b)
  .maxstack  2
  .locals init (object V_0,
           object[] V_1,
           int32 V_2)
  IL_0000:  ldarg.0
  IL_0001:  stloc.1
  IL_0002:  ldc.i4.0
  IL_0003:  stloc.2
  IL_0004:  br.s       IL_0014
  IL_0006:  ldloc.1
  IL_0007:  ldloc.2
  IL_0008:  ldelem.ref
  IL_0009:  stloc.0
  IL_000a:  ldloc.0
  IL_000b:  call       void [mscorlib]System.Console::WriteLine(object)
  IL_0010:  ldloc.2
  IL_0011:  ldc.i4.1
  IL_0012:  add
  IL_0013:  stloc.2
  IL_0014:  ldloc.2
  IL_0015:  ldloc.1
  IL_0016:  ldlen
  IL_0017:  conv.i4
  IL_0018:  blt.s      IL_0006
  IL_001a:  ret
} // end of method Test::IterateOverArray

Fait intéressant, je ne peux trouver cela documenté dans la spécification C # 3 nulle part ...

Une forboucle est compilée en code à peu près équivalent à ceci:

int tempCount = 0;
while (tempCount < list.Count)
{
    if (list[tempCount].value == value)
    {
        // Do something
    }
    tempCount++;
}

Où une foreachboucle est compilée en code à peu près équivalent à ceci:

using (IEnumerator<T> e = list.GetEnumerator())
{
    while (e.MoveNext())
    {
        T o = (MyClass)e.Current;
        if (row.value == value)
        {
            // Do something
        }
    }
}

Donc, comme vous pouvez le voir, tout dépendrait de la façon dont l'énumérateur est implémenté par rapport à la façon dont l'indexeur de listes est implémenté. Il s'avère que l'énumérateur pour les types basés sur des tableaux est normalement écrit quelque chose comme ceci:

private static IEnumerable<T> MyEnum(List<T> list)
{
    for (int i = 0; i < list.Count; i++)
    {
        yield return list[i];
    }
}

Donc, comme vous pouvez le voir, dans ce cas, cela ne fera pas beaucoup de différence, mais l'énumérateur d'une liste liée ressemblerait probablement à ceci:

private static IEnumerable<T> MyEnum(LinkedList<T> list)
{
    LinkedListNode<T> current = list.First;
    do
    {
        yield return current.Value;
        current = current.Next;
    }
    while (current != null);
}

Dans .NET, vous constaterez que la classe LinkedList <T> n'a même pas d'indexeur, vous ne pourrez donc pas faire votre boucle for sur une liste liée; mais si vous pouviez, l'indexeur devrait être écrit comme ceci:

public T this[int index]
{
       LinkedListNode<T> current = this.First;
       for (int i = 1; i <= index; i++)
       {
            current = current.Next;
       }
       return current.value;
}

Comme vous pouvez le voir, appeler cela plusieurs fois dans une boucle sera beaucoup plus lent que d'utiliser un énumérateur qui peut se rappeler où il se trouve dans la liste.

Un test facile à semi-valider. J'ai fait un petit test, juste pour voir. Voici le code:

static void Main(string[] args)
{
    List<int> intList = new List<int>();

    for (int i = 0; i < 10000000; i++)
    {
        intList.Add(i);
    }

    DateTime timeStarted = DateTime.Now;
    for (int i = 0; i < intList.Count; i++)
    {
        int foo = intList[i] * 2;
        if (foo % 2 == 0)
        {
        }
    }

    TimeSpan finished = DateTime.Now - timeStarted;

    Console.WriteLine(finished.TotalMilliseconds.ToString());
    Console.Read();

}

Et voici la section foreach:

foreach (int i in intList)
{
    int foo = i * 2;
    if (foo % 2 == 0)
    {
    }
}

Lorsque j'ai remplacé le for par un foreach - le foreach était 20 millisecondes plus rapide - de manière cohérente . Le pour était de 135-139ms tandis que le foreach était de 113-119ms. J'ai échangé plusieurs fois d'avant en arrière, m'assurant que ce n'était pas un processus qui venait juste de démarrer.

Cependant, lorsque j'ai supprimé l'instruction foo et if, le for était plus rapide de 30 ms (foreach était de 88 ms et for était de 59 ms). C'étaient tous les deux des coquilles vides. Je suppose que le foreach a en fait passé une variable alors que le for incrémentait simplement une variable. Si j'ai ajouté

int foo = intList[i];

Ensuite, le for devient lent d'environ 30 ms. Je suppose que cela a à voir avec la création de foo et la saisie de la variable dans le tableau et son affectation à foo. Si vous accédez simplement à intList [i], vous n'avez pas cette pénalité.

En toute honnêteté, je m'attendais à ce que le foreach soit légèrement plus lent dans toutes les circonstances, mais pas assez pour avoir de l'importance dans la plupart des applications.

edit: voici le nouveau code utilisant les suggestions Jons (134217728 est le plus grand int que vous puissiez avoir avant que l'exception System.OutOfMemory ne soit levée):

static void Main(string[] args)
{
    List<int> intList = new List<int>();

    Console.WriteLine("Generating data.");
    for (int i = 0; i < 134217728 ; i++)
    {
        intList.Add(i);
    }

    Console.Write("Calculating for loop:\t\t");

    Stopwatch time = new Stopwatch();
    time.Start();
    for (int i = 0; i < intList.Count; i++)
    {
        int foo = intList[i] * 2;
        if (foo % 2 == 0)
        {
        }
    }

    time.Stop();
    Console.WriteLine(time.ElapsedMilliseconds.ToString() + "ms");
    Console.Write("Calculating foreach loop:\t");
    time.Reset();
    time.Start();

    foreach (int i in intList)
    {
        int foo = i * 2;
        if (foo % 2 == 0)
        {
        }
    }

    time.Stop();

    Console.WriteLine(time.ElapsedMilliseconds.ToString() + "ms");
    Console.Read();
}

Et voici les résultats:

Générer des données. Calcul de la boucle for: 2458ms Calcul de la boucle foreach: 2005ms

Les échanger pour voir si cela traite de l'ordre des choses donne (presque) les mêmes résultats.

Remarque: cette réponse s'applique plus à Java qu'à C #, car C # n'a pas d'indexeur LinkedLists, mais je pense que le point général est toujours valable.

Si listvous travaillez avec un LinkedList, les performances du code indexeur ( accès de type tableau ) sont bien pires que l'utilisation de IEnumeratorfrom the foreach, pour de grandes listes.

Lorsque vous accédez à l'élément 10.000 dans a en LinkedListutilisant la syntaxe de l'indexeur:, list[10000]la liste chaînée commencera au nœud principal et traversera le Nextpointeur dix mille fois, jusqu'à ce qu'elle atteigne l'objet correct. Évidemment, si vous faites cela en boucle, vous obtiendrez:

list[0]; // head
list[1]; // head.Next
list[2]; // head.Next.Next
// etc.

Lorsque vous appelez GetEnumerator(en utilisant implicitement la forachsyntaxe -syntaxe), vous obtiendrez un IEnumeratorobjet qui a un pointeur vers le nœud principal. Chaque fois que vous appelez MoveNext, ce pointeur est déplacé vers le nœud suivant, comme ceci:

IEnumerator em = list.GetEnumerator();  // Current points at head
em.MoveNext(); // Update Current to .Next
em.MoveNext(); // Update Current to .Next
em.MoveNext(); // Update Current to .Next
// etc.

Comme vous pouvez le voir, dans le cas de LinkedLists, la méthode d'indexation de tableau devient de plus en plus lente, plus la boucle est longue (elle doit passer par le même pointeur de tête encore et encore). Alors que le IEnumerablejuste fonctionne en temps constant.

Bien sûr, comme Jon l'a dit, cela dépend vraiment du type de list, si le listn'est pas un LinkedList, mais un tableau, le comportement est complètement différent.

Comme d'autres personnes l'ont mentionné, bien que les performances n'aient pas vraiment d'importance, le foreach sera toujours un peu plus lent à cause de l' utilisation IEnumerable/ IEnumeratordans la boucle. Le compilateur traduit la construction en appels sur cette interface et pour chaque étape une fonction + une propriété est appelée dans la construction foreach.

IEnumerator iterator = ((IEnumerable)list).GetEnumerator();
while (iterator.MoveNext()) {
  var item = iterator.Current;
  // do stuff
}

C'est le développement équivalent de la construction en C #. Vous pouvez imaginer comment l'impact sur les performances peut varier en fonction des implémentations de MoveNext et Current. Alors que dans un accès à un tableau, vous n'avez pas ces dépendances.

Après avoir lu suffisamment d'arguments pour dire que "la boucle foreach devrait être préférée pour la lisibilité", je peux dire que ma première réaction a été "quoi"? La lisibilité, en général, est subjective et, dans ce cas particulier, encore plus. Pour quelqu'un avec une formation en programmation (pratiquement, tous les langages avant Java), les boucles for sont beaucoup plus faciles à lire que les boucles foreach. De plus, les mêmes personnes affirmant que les boucles foreach sont plus lisibles, sont également des partisans de linq et d'autres «fonctionnalités» qui rendent le code difficile à lire et à maintenir, ce qui prouve le point ci-dessus.

À propos de l'impact sur les performances, voyez la réponse à cette question.

EDIT: Il existe des collections en C # (comme le HashSet) qui n'ont pas d'indexeur. Dans ces collections, foreach est le seul moyen d'itérer et il est le seul cas , je pense qu'il devrait être utilisé plus pour .

Il y a un autre fait intéressant qui peut être facilement manqué lors du test de la vitesse des deux boucles: l'utilisation du mode de débogage ne permet pas au compilateur d'optimiser le code en utilisant les paramètres par défaut.

Cela m'a conduit au résultat intéressant que foreach est plus rapide qu'en mode débogage. Alors que le for est plus rapide que foreach en mode release. De toute évidence, le compilateur a de meilleures façons d'optimiser une boucle for qu'une boucle foreach qui compromet plusieurs appels de méthode. Une boucle for est d'ailleurs si fondamentale qu'il est possible qu'elle soit même optimisée par le processeur lui-même.

Dans l'exemple que vous avez fourni, il est certainement préférable d'utiliser une foreachboucle plutôt qu'une forboucle.

La foreachconstruction standard peut être plus rapide (1,5 cycles par étape) qu'une simple for-loop(2 cycles par étape), à ​​moins que la boucle n'ait été déroulée (1,0 cycle par étape).

Donc , pour le code de tous les jours, les performances ne sont pas une raison d'utiliser les plus complexes for, whileou des do-whileconstructions.

Consultez ce lien: http://www.codeproject.com/Articles/146797/Fast-and-Less-Fast-Loops-in-C

╔══════════════════════╦═══════════╦═══════╦════════════════════════╦═════════════════════╗
║        Method        ║ List<int> ║ int[] ║ Ilist<int> onList<Int> ║ Ilist<int> on int[] ║
╠══════════════════════╬═══════════╬═══════╬════════════════════════╬═════════════════════╣
║ Time (ms)            ║ 23,80     ║ 17,56 ║ 92,33                  ║ 86,90               ║
║ Transfer rate (GB/s) ║ 2,82      ║ 3,82  ║ 0,73                   ║ 0,77                ║
║ % Max                ║ 25,2%     ║ 34,1% ║ 6,5%                   ║ 6,9%                ║
║ Cycles / read        ║ 3,97      ║ 2,93  ║ 15,41                  ║ 14,50               ║
║ Reads / iteration    ║ 16        ║ 16    ║ 16                     ║ 16                  ║
║ Cycles / iteration   ║ 63,5      ║ 46,9  ║ 246,5                  ║ 232,0               ║
╚══════════════════════╩═══════════╩═══════╩════════════════════════╩═════════════════════╝

vous pouvez en savoir plus sur Deep .NET - partie 1 Itération

il couvre les résultats (sans la première initialisation) du code source .NET jusqu'au désassemblage.

par exemple - Array Itération avec une boucle foreach:

et - itération de liste avec la boucle foreach:

et les résultats finaux: