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

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

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

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

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

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

• for loops on List are a bit more than 2 times cheaper than foreach loops on List.
• Looping on array is around 2 times cheaper than looping on List.
• As a consequence, looping on array using for is 5 times cheaper than looping on List using foreach (which I believe, is what we all do).

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

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

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

foreach (int i in myCollection)

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

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

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

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

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

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

Во-первых, встречный иск к Ответ Дмитрия (сейчас удален). Для массивов компилятор 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

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

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

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

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

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

Я не ожидал, что кто-то обнаружит «огромную» разницу в производительности между ними.

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

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

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

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

"I have come to learn over the years the C# compiler is basically a liar to me." .. "It lies about many things." .. "Like when you do a foreach loop..." .. "...that is one little line of code that you write, but what the C# compiler spits out in order to do that it's phenomenal. It puts out a try/finally block in there, inside the finally block it casts your variable to an IDisposable interface, and if the cast suceeds it calls the Dispose method on it, inside the loop it calls the Current property and the MoveNext method repeatedly inside the loop, objects are being created underneath the covers. A lot of people use foreach because it's very easy coding, very easy to do.." .. "foreach is not very good in terms of performance, if you iterated over a collection instead by using square bracket notation, just doing index, that's just much faster, and it doesn't create any objects on the heap..."

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

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

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

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

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

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

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

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

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

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

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

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

Используйте класс 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, с точки зрения производительности или чего-то еще.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я думаю, что for в большинстве случаев немного быстрее, чем foreach, но это действительно упускает суть. Одна вещь, о которой я не упоминал, заключается в том, что в сценарии, о котором вы говорите (то есть в веб-приложении большого объема), разница в производительности между for и foreach не будет иметь никакого отношения к производительности сайта. Вы будете ограничены временем запроса / ответа и временем БД, а не v. Foreach.

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

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

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

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

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

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

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

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);
}

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

В моем проекте в Windows Mobile я использовал цикл for для контрольной коллекции. На 20 элементов управления ушло 100 ms! Цикл foreach использовал только 4 ms. Это была проблема с производительностью ...

Начиная с .NET Framework 4, вы также можете использовать Parallel.For и Parallel.ForEach, как описано здесь: Многопоточный цикл C# с Parallel.For или Parallel.ForEach

Я нашел цикл 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 быстрее, чем следующий,

• Цикл по каждому элементу с массивом.
• Для цикла со списком.
• Цикл по каждому элементу со списком.

См. Результаты моих тестов и код ниже,

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);
    }

Мне нужно было выполнить синтаксический анализ некоторых больших данных с помощью трех вложенных циклов (на List<MyCustomType>). Я подумал, используя сообщение Роба Фонсека-Энсора выше, было бы интересно время и сравнить разницу, используя для и для каждого.

Разница была: Foreach (три вложенных foreach, например, foreach {foreach {forech {}}} выполняли задание за 171,441 секунд, тогда как as for (for {for {for {}}}) выполняли его за 158,616 секунд.

Теперь 13 секунд - это сокращение 13% времени на это, что в некоторой степени важно для меня. Однако foreach определенно более читабелен, чем использование трех индексированных for ...

Здесь есть те же два ответа, что и на большинство вопросов "что быстрее":

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

2) (Потому что ...) Это зависит от обстоятельств.

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

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

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

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

Бен Уотсон, автор книги «Написание высокопроизводительного кода .NET»:

"Will these optimization matter to your program? Only if your program is CPU bound and collection iteration is a core part of your processing. As you'll see, there are ways you can hurt your performance if you're not careful, but that only matters if it was a significant part of your program to begin with. My philosophy is this: most people never need to know this, but if you do, then understanding every layer of the system is important so that you can make intelligent choices".

Наиболее исчерпывающее объяснение можно найти здесь: http://www.codeproject.com/Articles/844781/Digging-Into-NET-Loop-Performance-Bounds-checking

Я упомянул об этих деталях, основываясь на скорости сбора в for и foreach.

List -For Loop немного быстрее, чем Foreach Loop

ArrayList - For Loop примерно в 2 раза быстрее, чем Foreach Loop.

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

Я столкнулся со случаем, когда foreach намного быстрее, чем For

почему foreach быстрее, чем цикл for при чтении строк richtextbox

У меня был случай, похожий на OP в этом вопросе.

Текстовое поле, читающее около 72 КБ строк, и я обращался к свойству Lines (которое на самом деле является методом получения). (И, по-видимому, часто в winforms есть методы получения, которые не являются O (1). Я полагаю, что это O (n), поэтому чем больше текстовое поле, тем больше времени требуется для получения значения из этого `` свойства ''. А в for У меня был цикл, поскольку у OP был for(int i=0;i<textBox1.lines.length;i++) str=textBox1.Lines[i], и он действительно был довольно медленным, поскольку он читал все текстовое поле каждый раз, когда читал строку, плюс он читал все текстовое поле каждый раз, когда проверял условие.

Джон Скит показывает, что вы можете сделать это, обращаясь к свойству Lines только один раз (даже не один раз за итерацию, только один раз). Скорее, чем дважды на каждой итерации (а это тонна раз). Сделайте строку [] strarrlines = textBox1.Lines; и пропустите строчки.

Но, безусловно, цикл for в довольно интуитивно понятной форме и доступ к свойству Lines очень неэффективен.

for (int i = 0; i < richTextBox.Lines.Length; i++)
{
    s = richTextBox.Lines[i];
}

для текстового поля или расширенного текстового поля это очень медленно.

OP, тестируя этот цикл на расширенном текстовом поле, обнаружил, что «с 15000 строками. Для цикла for потребовалось 8 минут, чтобы просто выполнить цикл до 15000 строк. Тогда как foreach потребовалось доли секунды для его перечисления».

OP по этой ссылке обнаружил, что этот foreach намного более эффективен, чем его (тот же OP) цикл for, упомянутый выше. Как и я.

   String s=String.Empty;
   foreach(string str in txtText.Lines)
    {
       s=str;
    }

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

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

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

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

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

    internal static void Test()
    {
        int LOOP_LENGTH = 10000000;
        Random random = new Random((int)DateTime.Now.ToFileTime());

        {
            Dictionary<int, int> dict = new Dictionary<int, int>();
            long first_memory = GC.GetTotalMemory(true);
            var stopWatch = Stopwatch.StartNew();
            for (int i = 0; i < 64; i++)
            {
                dict.Add(i, i);
            }

            for (int i = 0; i < LOOP_LENGTH; i++)
            {
                for (int k = 0; k < dict.Count; k++)
                {
                    if (dict[k] > 1000000) Console.WriteLine("Test");
                }
            }
            stopWatch.Stop();
            var last_memory = GC.GetTotalMemory(true);
            Console.WriteLine($"Dictionary for T:{stopWatch.Elapsed.TotalSeconds}s\t M:{last_memory - first_memory}");

            GC.Collect();
        }


        {
            Dictionary<int, int> dict = new Dictionary<int, int>();
            long first_memory = GC.GetTotalMemory(true);
            var stopWatch = Stopwatch.StartNew();
            for (int i = 0; i < 64; i++)
            {
                dict.Add(i, i);
            }

            for (int i = 0; i < LOOP_LENGTH; i++)
            {
                foreach (var item in dict)
                {
                    if (item.Value > 1000000) Console.WriteLine("Test");
                }
            }
            stopWatch.Stop();
            var last_memory = GC.GetTotalMemory(true);
            Console.WriteLine($"Dictionary foreach T:{stopWatch.Elapsed.TotalSeconds}s\t M:{last_memory - first_memory}");

            GC.Collect();
        }

        {
            Dictionary<int, int> dict = new Dictionary<int, int>();
            long first_memory = GC.GetTotalMemory(true);
            var stopWatch = Stopwatch.StartNew();
            for (int i = 0; i < 64; i++)
            {
                dict.Add(i, i);
            }

            for (int i = 0; i < LOOP_LENGTH; i++)
            {
                foreach (var item in dict.Values)
                {
                    if (item > 1000000) Console.WriteLine("Test");
                }
            }
            stopWatch.Stop();
            var last_memory = GC.GetTotalMemory(true);
            Console.WriteLine($"Dictionary foreach values T:{stopWatch.Elapsed.TotalSeconds}s\t M:{last_memory - first_memory}");

            GC.Collect();
        }


        {
            List<int> dict = new List<int>();
            long first_memory = GC.GetTotalMemory(true);
            var stopWatch = Stopwatch.StartNew();
            for (int i = 0; i < 64; i++)
            {
                dict.Add(i);
            }

            for (int i = 0; i < LOOP_LENGTH; i++)
            {
                for (int k = 0; k < dict.Count; k++)
                {
                    if (dict[k] > 1000000) Console.WriteLine("Test");
                }
            }
            stopWatch.Stop();
            var last_memory = GC.GetTotalMemory(true);
            Console.WriteLine($"list for T:{stopWatch.Elapsed.TotalSeconds}s\t M:{last_memory - first_memory}");

            GC.Collect();
        }


        {
            List<int> dict = new List<int>();
            long first_memory = GC.GetTotalMemory(true);
            var stopWatch = Stopwatch.StartNew();
            for (int i = 0; i < 64; i++)
            {
                dict.Add(i);
            }

            for (int i = 0; i < LOOP_LENGTH; i++)
            {
                foreach (var item in dict)
                {
                    if (item > 1000000) Console.WriteLine("Test");
                }
            }
            stopWatch.Stop();
            var last_memory = GC.GetTotalMemory(true);
            Console.WriteLine($"list foreach T:{stopWatch.Elapsed.TotalSeconds}s\t M:{last_memory - first_memory}");

            GC.Collect();
        }
    }

Словарь для T: 10.1957728s M: 2080
Словарь foreach T: 10.5900586s M: 1952
Словарь для каждого значения T: 3.8294776s M: 2088
список для T: 3.7981471s M: 320
list foreach T: 4.4861377s M: 648