Quel est le plus efficace boucle en c#

La réponse de la majorité du temps est il n'a pas d'importance. Le nombre d'éléments dans la boucle (encore que ce que l'on pourrait considérer comme un "grand" nombre d'éléments, par exemple dans les milliers) ne va pas avoir un impact sur le code.

Bien sûr, si vous l'identifier comme un goulot d'étranglement dans votre situation, par tous les moyens, de l'adresse, mais vous devez identifier le goulot d'étranglement de la première.

Cela dit, il y a un certain nombre de choses à prendre en considération à chaque approche, que je vais décrire ici.

Nous allons définir quelques choses d'abord:

• Tous les tests ont été exécutés sur .NET 4.0 sur un processeur 32 bits.
• laps de Temps.TicksPerSecond sur ma machine = 10 000 000 de
• Tous les tests ont été effectués dans une unité distincte séances de test, pas dans le même (afin de ne pas éventuellement interférer avec la collecte des poubelles, etc.)

Voici quelques assistants qui sont nécessaires pour chaque test:

La MyObject classe:

public class MyObject
{
    public int IntValue { get; set; }
    public double DoubleValue { get; set; }
}

Une méthode pour créer un List<T> de n'importe quelle longueur de MyClass instances:

public static List<MyObject> CreateList(int items)
{
    //Validate parmaeters.
    if (items < 0) 
        throw new ArgumentOutOfRangeException("items", items, 
            "The items parameter must be a non-negative value.");

    //Return the items in a list.
    return Enumerable.Range(0, items).
        Select(i => new MyObject { IntValue = i, DoubleValue = i }).
        ToList();
}

Une action à effectuer pour chaque élément de la liste (ce qui est nécessaire parce que la Méthode 2 utilise un délégué, et un appel doit être faite à quelque chose afin de mesurer l'impact):

public static void MyObjectAction(MyObject obj, TextWriter writer)
{
    //Validate parameters.
    Debug.Assert(obj != null);
    Debug.Assert(writer != null);

    //Write.
    writer.WriteLine("MyObject.IntValue: {0}, MyObject.DoubleValue: {1}", 
        obj.IntValue, obj.DoubleValue);
}

Une méthode pour créer un TextWriter qui écrit sur un null Stream (essentiellement des données de l'évier):

public static TextWriter CreateNullTextWriter()
{
    //Create a stream writer off a null stream.
    return new StreamWriter(Stream.Null);
}

Et nous allons fixer le nombre d'éléments à un million (1 000 000, qui devrait être suffisamment élevé pour faire valoir ce que de façon générale, ces toutes sur le même impact sur les performances):

//The number of items to test.
public const int ItemsToTest = 1000000;

Nous allons entrer dans les méthodes:

Méthode 1: foreach

Le code suivant:

foreach(var item in myList) 
{
   //Do stuff
}

Compile vers le bas dans le texte suivant:

using (var enumerable = myList.GetEnumerable())
while (enumerable.MoveNext())
{
    var item = enumerable.Current;

    //Do stuff.
}

Il est tout à fait un peu là. Vous avez les appels de méthode (et il peut ou ne peut pas être contre la IEnumerator<T> ou IEnumerator interfaces, comme le compilateur respecte canard-typage dans ce cas) et votre //Do stuff est hissé dans que alors que la structure.

Voici le test de mesure de la performance:

[TestMethod]
public void TestForEachKeyword()
{
    //Create the list.
    List<MyObject> list = CreateList(ItemsToTest);

    //Create the writer.
    using (TextWriter writer = CreateNullTextWriter())
    {
        //Create the stopwatch.
        Stopwatch s = Stopwatch.StartNew();

        //Cycle through the items.
        foreach (var item in list)
        {
            //Write the values.
            MyObjectAction(item, writer);
        }

        //Write out the number of ticks.
        Debug.WriteLine("Foreach loop ticks: {0}", s.ElapsedTicks);
    }
}

La sortie:

Boucle Foreach tiques: 3210872841

Méthode 2: .ForEach méthode sur List<T>

Le code de la .ForEach méthode sur List<T> ressemble à quelque chose comme ceci:

public void ForEach(Action<T> action)
{
    //Error handling omitted

    //Cycle through the items, perform action.
    for (int index = 0; index < Count; ++index)
    {
        //Perform action.
        action(this[index]);
    }
}

Noter que c'est fonctionnellement équivalente à la Méthode 4, à une exception près, le code qui est hissé dans le for boucle est passée en tant que délégué. Cela nécessite un déréférencement pour obtenir le code qui doit être exécuté. Bien que la performance des délégués s'est améliorée .NET 3.0 sur, que les frais généraux est là.

Cependant, il est négligeable. Le test de mesure de la performance:

[TestMethod]
public void TestForEachMethod()
{
    //Create the list.
    List<MyObject> list = CreateList(ItemsToTest);

    //Create the writer.
    using (TextWriter writer = CreateNullTextWriter())
    {
        //Create the stopwatch.
        Stopwatch s = Stopwatch.StartNew();

        //Cycle through the items.
        list.ForEach(i => MyObjectAction(i, writer));

        //Write out the number of ticks.
        Debug.WriteLine("ForEach method ticks: {0}", s.ElapsedTicks);
    }
}

La sortie:

ForEach méthode tiques: 3135132204

C'est fait ~7,5 secondes plus rapide que l'utilisation de la foreach boucle. Pas tout à fait surprenant, étant donné qu'il utilise directement accès au tableau au lieu d'utiliser IEnumerable<T>.

Rappelez-vous cependant, ce qui se traduit par 0.0000075740637 secondes par point d'être sauvé. C'est pas la peine pour les petites listes d'éléments.

Méthode 3: while (myList.MoveNext())

Comme indiqué dans la Méthode 1, c'est exactement ce que le compilateur n' (avec l'ajout de la using déclaration, qui est bien pratique). Vous n'êtes pas gagner quoi que ce soit ici en déroulant le code vous-même, que le compilateur aurait autrement générer.

Pour les coups de pied, nous allons le faire de toute façon:

[TestMethod]
public void TestEnumerator()
{
    //Create the list.
    List<MyObject> list = CreateList(ItemsToTest);

    //Create the writer.
    using (TextWriter writer = CreateNullTextWriter())
    //Get the enumerator.
    using (IEnumerator<MyObject> enumerator = list.GetEnumerator())
    {
        //Create the stopwatch.
        Stopwatch s = Stopwatch.StartNew();

        //Cycle through the items.
        while (enumerator.MoveNext())
        {
            //Write.
            MyObjectAction(enumerator.Current, writer);
        }

        //Write out the number of ticks.
        Debug.WriteLine("Enumerator loop ticks: {0}", s.ElapsedTicks);
    }
}

La sortie:

Énumérateur de la boucle de tiques: 3241289895

Méthode 4: for

Dans ce cas particulier, vous allez obtenir une vitesse, comme la liste de l'indexeur est d'aller directement dans le sous-tableau pour effectuer la recherche (c'est un détail d'implémentation, d'ailleurs, il n'y a rien à dire qu'il ne peut pas être une structure de l'arbre de la sauvegarde de la List<T> jusqu').

[TestMethod]
public void TestListIndexer()
{
    //Create the list.
    List<MyObject> list = CreateList(ItemsToTest);

    //Create the writer.
    using (TextWriter writer = CreateNullTextWriter())
    {
        //Create the stopwatch.
        Stopwatch s = Stopwatch.StartNew();

        //Cycle by index.
        for (int i = 0; i < list.Count; ++i)
        {
            //Get the item.
            MyObject item = list[i];

            //Perform the action.
            MyObjectAction(item, writer);
        }

        //Write out the number of ticks.
        Debug.WriteLine("List indexer loop ticks: {0}", s.ElapsedTicks);
    }
}

La sortie:

Liste indexeur boucle tiques: 3039649305

Cependant le lieu où cette peut faire une différence est tableaux. Les tableaux peuvent être dénoué par le compilateur de traiter plusieurs éléments à la fois.

Au lieu de faire dix itérations d'un élément dans une dizaine de point de boucle, le compilateur peut se détendre en cinq itérations de deux éléments dans une dizaine d'élément de boucle.

Cependant, je ne suis pas positif ici que ce qui se passe réellement (je dois regarder le IL et la sortie de la compilation IL).

Voici le test:

[TestMethod]
public void TestArray()
{
    //Create the list.
    MyObject[] array = CreateList(ItemsToTest).ToArray();

    //Create the writer.
    using (TextWriter writer = CreateNullTextWriter())
    {
        //Create the stopwatch.
        Stopwatch s = Stopwatch.StartNew();

        //Cycle by index.
        for (int i = 0; i < array.Length; ++i)
        {
            //Get the item.
            MyObject item = array[i];

            //Perform the action.
            MyObjectAction(item, writer);
        }

        //Write out the number of ticks.
        Debug.WriteLine("Enumerator loop ticks: {0}", s.ElapsedTicks);
    }
}

La sortie:

Boucle de tableau tiques: 3102911316

Il convient de noter que out-of-the-box, Resharper propose une suggestion avec un refactoring pour changer le ci-dessus for déclarations foreach consolidés. Ce n'est pas de dire ce qui est juste, mais la base est de réduire le montant de la dette technique dans le code.

---

TL;DR

Vous ne devriez pas être concerné par la performance de ces choses, à moins que des tests dans votre situation montre que vous avez un véritable goulot d'étranglement (et que vous aurez d'avoir d'énormes quantités d'éléments pour avoir un impact).

En général, vous devriez aller pour ce qui est plus facile à maintenir, dans ce cas, la Méthode 1 (foreach) est le chemin à parcourir.