В C # / VB.NET / .NET какой цикл работает быстрее forили foreach?

С тех пор, как я прочитал, что forцикл работает быстрее, чем foreachцикл давным-давно, я предположил, что это верно для всех коллекций, универсальных коллекций, всех массивов и т. Д.

Я просмотрел Google и нашел несколько статей, но большинство из них неубедительны (читай комментарии к статьям) и открыты.

Что было бы идеально, так это иметь каждый сценарий в списке и лучшее решение для него.

Например (просто пример того, как это должно быть):

1. для перебора массива из 1000+ строк - forлучше, чемforeach
2. для перебора IList(не универсальных) строк - foreachлучше, чемfor

Несколько ссылок, найденных в Интернете для того же:

1. Оригинальная старая статья Эммануэля Шанцера
2. CodeProject FOREACH Vs. ДЛЯ
3. Блог - к foreachили нет foreach, вот в чем вопрос
4. Форум ASP.NET - NET 1.1 C # forпротивforeach

[Редактировать]

Помимо аспекта читабельности, меня действительно интересуют факты и цифры. Существуют приложения, в которых важна последняя миля оптимизации производительности.

Об этом в прошлом месяце написал Патрик Смаккья со следующими выводами:

• Циклы for в List чуть более чем в 2 раза дешевле, чем циклы foreach в List.
• Зацикливание в массиве примерно в 2 раза дешевле, чем зацикливание в List.
• Как следствие, зацикливание на использовании массива for в 5 раз дешевле, чем зацикливание на List с использованием foreach (что, я считаю, является тем, что мы все делаем).

Сначала встречный иск к ответу Дмитрия (теперь удален) . Для массивов компилятор C # выдает в основном тот же код, foreachчто и для эквивалентного forцикла. Это объясняет, почему для этого теста результаты в основном такие же:

using System;
using System.Diagnostics;
using System.Linq;

class Test
{
    const int Size = 1000000;
    const int Iterations = 10000;

    static void Main()
    {
        double[] data = new double[Size];
        Random rng = new Random();
        for (int i=0; i < data.Length; i++)
        {
            data[i] = rng.NextDouble();
        }

        double correctSum = data.Sum();

        Stopwatch sw = Stopwatch.StartNew();
        for (int i=0; i < Iterations; i++)
        {
            double sum = 0;
            for (int j=0; j < data.Length; j++)
            {
                sum += data[j];
            }
            if (Math.Abs(sum-correctSum) > 0.1)
            {
                Console.WriteLine("Summation failed");
                return;
            }
        }
        sw.Stop();
        Console.WriteLine("For loop: {0}", sw.ElapsedMilliseconds);

        sw = Stopwatch.StartNew();
        for (int i=0; i < Iterations; i++)
        {
            double sum = 0;
            foreach (double d in data)
            {
                sum += d;
            }
            if (Math.Abs(sum-correctSum) > 0.1)
            {
                Console.WriteLine("Summation failed");
                return;
            }
        }
        sw.Stop();
        Console.WriteLine("Foreach loop: {0}", sw.ElapsedMilliseconds);
    }
}

Полученные результаты:

For loop: 16638
Foreach loop: 16529

Далее, проверка того, что Грег говорит о важности типа коллекции - измените массив на a List<double>в приведенном выше, и вы получите радикально разные результаты. Это не только значительно медленнее в целом, но foreach становится значительно медленнее, чем доступ по индексу. Сказав это, я все равно почти всегда предпочитаю foreach циклу for, где он упрощает код - потому что читаемость почти всегда важна, а микрооптимизация редко.

foreachциклы демонстрируют более конкретное намерение, чем forциклы .

Использование foreachцикла демонстрирует любому, кто использует ваш код, что вы планируете что-то сделать для каждого члена коллекции независимо от его места в коллекции. Это также показывает, что вы не изменяете исходную коллекцию (и выдает исключение, если вы пытаетесь это сделать).

Другое преимущество foreachзаключается в том, что он работает в любом месте IEnumerable, где forимеет смысл только то IList, где каждый элемент имеет индекс.

Однако, если вам нужно использовать индекс элемента, тогда, конечно, вам должно быть разрешено использовать forцикл. Но если вам не нужно использовать индекс, его наличие просто загромождает ваш код.

Насколько я знаю, никаких существенных последствий для производительности нет. На каком-то этапе в будущем будет проще адаптировать код foreachдля работы на нескольких ядрах, но сейчас не о чем беспокоиться.

Каждый раз, когда возникают споры по поводу производительности, вам просто нужно написать небольшой тест, чтобы вы могли использовать количественные результаты для поддержки вашего случая.

Используйте класс StopWatch и повторите что-то несколько миллионов раз для точности. (Это может быть трудно без цикла for):

using System.Diagnostics;
//...
Stopwatch sw = new Stopwatch()
sw.Start()
for(int i = 0; i < 1000000;i ++)
{
    //do whatever it is you need to time
}
sw.Stop();
//print out sw.ElapsedMilliseconds

Пальцы пересекли результаты этого шоу, что разница незначительна, и вы могли бы просто сделать любые результаты в наиболее поддерживаемом коде

Это всегда будет близко. Для массива иногда for немного быстрее, но foreachон более выразителен и предлагает LINQ и т. Д. В общем, придерживайтесьforeach .

Кроме того, foreachможет быть оптимизирован в некоторых сценариях. Например, связанный список может быть ужасным для индексатора, но он может быть быстрым foreach. На самом деле, стандарт LinkedList<T>даже не предлагает индексатор по этой причине.

Я предполагаю, что это, вероятно, не будет значимым в 99% случаев, так почему бы вам выбрать более быстрый, а не наиболее подходящий (как это проще всего понять / сохранить)?

Вряд ли между ними будет огромная разница в производительности. Как всегда, когда сталкиваешься с "что быстрее?" Вопрос, вы всегда должны думать: «Я могу измерить это».

Напишите два цикла, которые делают одно и то же в теле цикла, выполните и рассчитайте их оба, и посмотрите, какова разница в скорости. Делайте это как с почти пустым телом, так и с телом цикла, похожим на то, что вы на самом деле будете делать. Также попробуйте это с типом коллекции, который вы используете, потому что разные типы коллекций могут иметь разные характеристики производительности.

Есть очень веские причины, чтобы предпочесть foreach петли над forпетлями. Если вы можете использовать foreachпетлю, ваш босс прав, что вы должны.

Однако не каждая итерация просто просматривает список по порядку. Если он запрещает , да, это неправильно.

На вашем месте я бы превратил все ваши естественные циклы в рекурсию . Это научит его, и это также хорошее умственное упражнение для вас.

Джеффри Рихтер на TechEd 2005:

«Я пришел к выводу, что на протяжении многих лет компилятор C # для меня лжец». .. "Это ложь о многих вещах." .. "Например, когда вы делаете цикл foreach ..." .. "... это одна маленькая строчка кода, которую вы пишете, но то, что выдает компилятор C # для того, чтобы сделать это, это феноменально. там блок try / finally, внутри блока finally он преобразует вашу переменную в интерфейс IDisposable, и если приведение завершается успешно, он вызывает для него метод Dispose, внутри цикла он вызывает свойство Current, а метод MoveNext несколько раз внутри цикла, объекты создаются под крышками. Многие люди используют foreach, потому что это очень легко кодировать, очень легко делать ... ".." foreach не очень хорош с точки зрения производительности,

Веб-трансляция по требованию: http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032292286&EventCategory=3&culture=en-US&CountryCode=US

Это смешно. Нет никаких веских причин, чтобы запретить цикл, производительность или другие.

См . Блог Джона Скита для оценки производительности и других аргументов.

В случаях, когда вы работаете с коллекцией объектов, foreachэто лучше, но если вы увеличиваете число, forцикл лучше.

Обратите внимание, что в последнем случае вы можете сделать что-то вроде:

foreach (int i in Enumerable.Range(1, 10))...

Но он, конечно, не работает лучше, на самом деле он хуже по сравнению с for.

Это должно спасти вас:

public IEnumerator<int> For(int start, int end, int step) {
    int n = start;
    while (n <= end) {
        yield n;
        n += step;
    }
}

Использование:

foreach (int n in For(1, 200, 4)) {
    Console.WriteLine(n);
}

Для большего выигрыша вы можете взять трех делегатов в качестве параметров.

Вы можете прочитать об этом в Deep .NET - часть 1 Итерация

он охватывает результаты (без первой инициализации) из исходного кода .NET вплоть до разборки.

например - Итерация массива с циклом foreach:

и - список итераций с циклом foreach:

и конечные результаты:

Различия в скорости в for- и foreach-loop крошечные, когда вы просматриваете общие структуры, такие как массивы, списки и т. Д., И делаетеLINQ запроса к коллекции почти всегда немного медленнее, хотя писать приятнее! Как говорили другие авторы, стремитесь к выразительности, а не к миллисекунде дополнительной производительности.

До сих пор не было сказано, что когда foreachцикл компилируется, он оптимизируется компилятором на основе коллекции, по которой он перебирает. Это означает, что когда вы не уверены, какой цикл использовать, вы должны использовать foreachцикл - он сгенерирует лучший цикл для вас, когда будет скомпилирован. Это также более читабельно.

Другое ключевое преимущество foreachцикла состоит в том, что если ваша реализация коллекции изменится (например, с int arrayна a List<int>), то ваш foreachцикл не потребует никаких изменений кода:

foreach (int i in myCollection)

Выше приведено одно и то же, независимо от типа вашей коллекции, тогда как в вашем forцикле следующее не будет построено, если вы изменили myCollectionс a arrayна a List:

for (int i = 0; i < myCollection.Length, i++)

«Есть ли какие-либо аргументы, которые я мог бы использовать, чтобы убедить его, что цикл for приемлем для использования?»

Нет, если ваш начальник на микроуровне говорит о том, какой язык программирования использовать, вам нечего сказать. Сожалею.

Вероятно, это зависит от типа коллекции, которую вы перечисляете, и от реализации ее индексатора. В целом, использование foreach, вероятно, будет лучшим подходом.

Кроме того, он будет работать с любыми IEnumerable- не только с индексаторами.

На это есть те же два ответа, что и на большинство вопросов «что быстрее»:

1) Если вы не измеряете, вы не знаете.

2) (потому что ...) Это зависит.

Это зависит от того, насколько дорогой метод "MoveNext ()", относительно того, насколько дорогой метод "this [int index]", для типа (или типов) IEnumerable, который вы будете перебирать.

Ключевое слово «foreach» является сокращением для ряда операций - оно вызывает GetEnumerator () один раз в IEnumerable, оно вызывает MoveNext () один раз за итерацию, выполняет некоторую проверку типов и так далее. Наиболее вероятным фактором, влияющим на измерения производительности, является стоимость MoveNext (), поскольку она вызывается O (N) раз. Может быть, это дешево, но, возможно, это не так.

Ключевое слово «for» выглядит более предсказуемым, но внутри большинства циклов «for» вы найдете что-то вроде «collection [index]». Это похоже на простую операцию индексации массива, но на самом деле это вызов метода, стоимость которого полностью зависит от природы коллекции, для которой вы выполняете итерацию. Возможно, это дешево, но, возможно, это не так.

Если базовая структура коллекции по сути представляет собой связанный список, MoveNext является дешевым, но индексатор может иметь стоимость O (N), что составляет истинную стоимость цикла for (O * N).

Каждая языковая конструкция имеет подходящее время и место для использования. Есть причина, по которой язык C # имеет четыре отдельных итерационных оператора - каждый из них предназначен для определенной цели и имеет соответствующее применение.

Я рекомендую сесть с вашим боссом и попытаться рационально объяснить, почему у forпетли есть цель. Есть моменты, когда forитерационный блок более четко описывает алгоритм, чем foreachитерация. Когда это правда, уместно использовать их.

Я также хотел бы отметить вашего босса - производительность не является и не должна быть проблемой в практическом плане - это скорее вопрос выражения алгоритма в сжатой, содержательной и понятной форме. Подобные микрооптимизации полностью упускают смысл оптимизации производительности, поскольку любое реальное преимущество в производительности будет достигнуто за счет алгоритмического реорганизации и рефакторинга, а не реструктуризации цикла.

Если после разумного обсуждения все еще существует авторитарный взгляд, то вам решать, как действовать дальше. Лично я не был бы счастлив работать в среде, где рациональное мышление не поощрялось, и подумал бы о переходе на другую должность под другого работодателя. Тем не менее, я настоятельно рекомендую обсудить до того, как расстроиться - может быть просто недоразумение.

Именно то, что вы делаете внутри цикла, влияет на производительность, а не на фактическую конструкцию цикла (если ваш случай нетривиален).

Будь forбыстрее, чем foreachна самом деле, кроме сути. Я серьезно сомневаюсь, что выбор одного из других окажет значительное влияние на вашу производительность.

Лучший способ оптимизировать ваше приложение - это профилирование реального кода. Это позволит точно определить методы, на которые приходится больше всего работы / времени. Оптимизируйте те сначала. Если производительность по-прежнему не приемлема, повторите процедуру.

Как правило, я бы рекомендовал держаться подальше от микрооптимизаций, поскольку они редко приносят какие-либо существенные выгоды. Единственное исключение - при оптимизации идентифицированных «горячих путей» (т. Е. Если ваше профилирование идентифицирует несколько широко используемых методов, возможно, имеет смысл оптимизировать их экстенсивно).

Два будут работать практически одинаково. Напишите некоторый код, чтобы использовать оба, затем покажите ему IL. Он должен показывать сопоставимые вычисления, что означает отсутствие различий в производительности.

for имеет более простую логику для реализации, поэтому она быстрее, чем foreach.

Если вы не участвуете в конкретном процессе оптимизации скорости, я бы сказал, что используйте тот метод, который позволяет легко читать и поддерживать код.

Если итератор уже настроен, как, например, с одним из классов коллекции, тогда foreach является хорошим простым вариантом. И если вы перебираете целочисленный диапазон, то, вероятно, он чище.

Джеффри Рихтер рассказал о разнице в производительности между for и foreach в недавнем подкасте: http://pixel8.infragistics.com/shows/everything.aspx#Episode:9317

В большинстве случаев нет никакой разницы.

Как правило, вы всегда должны использовать foreach, когда у вас нет явного числового индекса, и вы всегда должны использовать его, когда у вас фактически нет итеративной коллекции (например, итерации по двумерной сетке массива в верхнем треугольнике) , В некоторых случаях у вас есть выбор.

Можно утверждать, что циклы for могут быть немного сложнее поддерживать, если в коде начинают появляться магические числа. Вы должны быть правы, если будете раздражены тем, что не можете использовать цикл for и должны собирать коллекцию или использовать лямбду для создания подколлекции вместо этого только потому, что циклы for были запрещены.

Кажется немного странным полностью запретить использование чего-то вроде цикла for.

Там интересная статья здесь , которая охватывает много различий в производительности между двумя петлями.

Я бы сказал, что лично я нахожу foreach немного более читаемым для циклов, но вы должны использовать лучшее для текущей работы и не нужно писать слишком длинный код для включения цикла foreach, если цикл for более уместен.

Я нашел foreachцикл, который перебирает List быстрее . Смотрите результаты моего теста ниже. В приведенном ниже коде я выполняю итерации arrayразмером 100, 10000 и 100000 по отдельности, используя цикл forи foreachцикл для измерения времени.

private static void MeasureTime()
    {
        var array = new int[10000];
        var list = array.ToList();
        Console.WriteLine("Array size: {0}", array.Length);

        Console.WriteLine("Array For loop ......");
        var stopWatch = Stopwatch.StartNew();
        for (int i = 0; i < array.Length; i++)
        {
            Thread.Sleep(1);
        }
        stopWatch.Stop();
        Console.WriteLine("Time take to run the for loop is {0} millisecond", stopWatch.ElapsedMilliseconds);

        Console.WriteLine(" ");
        Console.WriteLine("Array Foreach loop ......");
        var stopWatch1 = Stopwatch.StartNew();
        foreach (var item in array)
        {
            Thread.Sleep(1);
        }
        stopWatch1.Stop();
        Console.WriteLine("Time take to run the foreach loop is {0} millisecond", stopWatch1.ElapsedMilliseconds);

        Console.WriteLine(" ");
        Console.WriteLine("List For loop ......");
        var stopWatch2 = Stopwatch.StartNew();
        for (int i = 0; i < list.Count; i++)
        {
            Thread.Sleep(1);
        }
        stopWatch2.Stop();
        Console.WriteLine("Time take to run the for loop is {0} millisecond", stopWatch2.ElapsedMilliseconds);

        Console.WriteLine(" ");
        Console.WriteLine("List Foreach loop ......");
        var stopWatch3 = Stopwatch.StartNew();
        foreach (var item in list)
        {
            Thread.Sleep(1);
        }
        stopWatch3.Stop();
        Console.WriteLine("Time take to run the foreach loop is {0} millisecond", stopWatch3.ElapsedMilliseconds);
    }

ОБНОВЛЕНО

После предложения @jgauffin я использовал код @johnskeet и обнаружил, что forцикл с arrayболее быстрым, чем следующий,

• Цикл Foreach с массивом.
• Для цикла со списком.
• Цикл Foreach со списком.

Смотрите результаты моего теста и код ниже,

private static void MeasureNewTime()
    {
        var data = new double[Size];
        var rng = new Random();
        for (int i = 0; i < data.Length; i++)
        {
            data[i] = rng.NextDouble();
        }
        Console.WriteLine("Lenght of array: {0}", data.Length);
        Console.WriteLine("No. of iteration: {0}", Iterations);
        Console.WriteLine(" ");
        double correctSum = data.Sum();

        Stopwatch sw = Stopwatch.StartNew();
        for (int i = 0; i < Iterations; i++)
        {
            double sum = 0;
            for (int j = 0; j < data.Length; j++)
            {
                sum += data[j];
            }
            if (Math.Abs(sum - correctSum) > 0.1)
            {
                Console.WriteLine("Summation failed");
                return;
            }
        }
        sw.Stop();
        Console.WriteLine("For loop with Array: {0}", sw.ElapsedMilliseconds);

        sw = Stopwatch.StartNew();
        for (var i = 0; i < Iterations; i++)
        {
            double sum = 0;
            foreach (double d in data)
            {
                sum += d;
            }
            if (Math.Abs(sum - correctSum) > 0.1)
            {
                Console.WriteLine("Summation failed");
                return;
            }
        }
        sw.Stop();
        Console.WriteLine("Foreach loop with Array: {0}", sw.ElapsedMilliseconds);
        Console.WriteLine(" ");

        var dataList = data.ToList();
        sw = Stopwatch.StartNew();
        for (int i = 0; i < Iterations; i++)
        {
            double sum = 0;
            for (int j = 0; j < dataList.Count; j++)
            {
                sum += data[j];
            }
            if (Math.Abs(sum - correctSum) > 0.1)
            {
                Console.WriteLine("Summation failed");
                return;
            }
        }
        sw.Stop();
        Console.WriteLine("For loop with List: {0}", sw.ElapsedMilliseconds);

        sw = Stopwatch.StartNew();
        for (int i = 0; i < Iterations; i++)
        {
            double sum = 0;
            foreach (double d in dataList)
            {
                sum += d;
            }
            if (Math.Abs(sum - correctSum) > 0.1)
            {
                Console.WriteLine("Summation failed");
                return;
            }
        }
        sw.Stop();
        Console.WriteLine("Foreach loop with List: {0}", sw.ElapsedMilliseconds);
    }

Вы можете действительно ввернуть его голову и пойти на IQueryable .foreach закрытие вместо этого:

myList.ForEach(c => Console.WriteLine(c.ToString());

Я не ожидал бы, что кто-нибудь найдет "огромную" разницу в производительности между этими двумя.

Я предполагаю, что ответ зависит от того, имеет ли доступ к коллекции, к которой вы пытаетесь получить, более быструю реализацию доступа к индексаторам или более быструю реализацию доступа IEnumerator. Поскольку IEnumerator часто использует индексатор и просто хранит копию текущей позиции индекса, я ожидаю, что доступ к перечислителю будет, по крайней мере, таким же медленным или медленным, как прямой доступ к индексу, но ненамного.

Конечно, этот ответ не учитывает никаких оптимизаций, которые может реализовать компилятор.

Имейте в виду, что цикл for и цикл foreach не всегда эквивалентны. Перечислители списка будут генерировать исключение, если список изменится, но вы не всегда получите это предупреждение с обычным циклом for. Вы можете даже получить другое исключение, если список меняется не вовремя.