Бенчмаркая foreach и энумераторы: аллокации, которые прятались 10 лет

Уважаемые читатели, в этой статье я хочу рассказать о скрытых аллокациях в обычном foreach и представить свои выводы. Тесты сделаны на .net 8, .net 9 и .net 10 одновременно, чтобы было видно, как одна и та же строчка кода ведет себя на разных рантаймах.

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

Будет три истории, и все три про foreach:

• SortedList из стандартной библиотеки аллоцирует память на каждый foreach, а Dictionary — нет. Из-за одной строчки в сигнатуре метода. И починить это по-нормальному нельзя.

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

• У новой оптимизации есть задокументированная самим Microsoft граница — на больших коллекциях она может срываться. Я пошел ловить этот обрыв с бенчмарком — и получилось интереснее, чем я ожидал.

Каждое утверждение подкреплено ссылкой на GitHub dotnet/runtime или на официальный блог .NET — специально собрал пруфы, чтобы можно было пойти и проверить первоисточник, а не верить мне на слово. Все ссылки продублированы списком в конце.

Тесты гонялись на четырех машинах — от игровых десктопов до двухпроцессорных серверов:

BenchmarkDotNet везде v0.15.8. Подробные таблицы по ходу статьи — с машины №2, по остальным привожу сводные сравнения. Обратите внимание на версии .NET 10: 10.0.1, 10.0.5 и 10.0.9 — три разные сервисные сборки, это еще сыграет роль в третьей истории.

Немного теории

Про foreach написано немало, поэтому сильно углубляться не буду, но немного напишу, что да как — иначе дальше будет непонятно, откуда берутся аллокации там, где нет ни одного new.

Энумератор — это маленький объект-курсор, который умеет две вещи: сдвинуться на следующий элемент (MoveNext()) и отдать текущий (Current). Когда вы пишете foreach, компилятор за кулисами берет у коллекции энумератор и крутит его в цикле while. То есть каждый foreach — это создание одного энумератора.

Дальше главный вопрос: где живет этот энумератор — на стеке (бесплатно, сборщик мусора про него даже не узнает) или на куче (аллокация, которую потом придется собирать GC)?

Тут есть неочевидный факт: foreach работает не через интерфейс, а через утиную типизацию — по классике: если это выглядит как утка, плавает как утка и крякает как утка — значит, это утка. Компилятору не нужен IEnumerable — ему нужен просто метод с именем GetEnumerator(). И компилятор берет тот метод, который видит по типу переменной. Поэтому у List<T> внутри целых три метода GetEnumerator:

// Так выглядит List<T> внутри (упрощенно): // 1. Публичный. Возвращает struct КАК ЕСТЬ. Его берет foreach,//    когда тип переменной - List<T>. Ноль аллокаций.public List<T>.Enumerator GetEnumerator()    => new List<T>.Enumerator(this); // 2. Явная реализация интерфейса. Возвращает ТОТ ЖЕ struct,//    но уже как интерфейс. Struct в интерфейсной переменной жить//    не может - происходит боксинг в объект на куче.IEnumerator<T> IEnumerable<T>.GetEnumerator()    => new List<T>.Enumerator(this); // 3. То же самое для старого необобщенного IEnumerable.IEnumerator IEnumerable.GetEnumerator()    => new List<T>.Enumerator(this);

Боксинг — это когда struct нужно передать туда, где ждут ссылку на объект. Рантайм выделяет объект на куче и копирует туда значение структуры. Каждый боксинг — это аллокация, и ее видно в колонке Allocated у BenchmarkDotNet.

А теперь пример, вокруг которого крутится вся статья. Код одинаковый, разница только в типе переменной:

var list = new List<int> { 1, 2, 3 }; // Тип переменной - List<int>. foreach берет метод №1.// Struct-энумератор живет на стеке. Аллокаций: 0.foreach (var n in list) { } // Тип переменной - IEnumerable<int>. foreach берет метод №2.// Тот же struct, но боксированный на кучу.// Аллокаций: 1 объект на каждый foreach.IEnumerable<int> seq = list;foreach (var n in seq) { }

Вот и вся теория. Никакого new в коде нет, а аллокация есть. Дальше — три истории, где эта мелочь оборачивается интересными последствиями, и бенчмарки, чтобы все пощупать руками.

История первая: SortedList, который аллоцирует, и никто не может это починить

В январе 2023 года разработчик под ником emilsteen завел в dotnet/runtime issue №81128. История максимально жизненная: у человека на проде foreach по маленькому SortedList на 15 элементов, он гоняет его миллион раз и видит в BenchmarkDotNet аллокации. А точно такой же foreach по Dictionary — ноль байт. Он не поленился и раскопал причину сам.

Причина — одна строчка. Сравните сигнатуры публичных методов GetEnumerator у двух коллекций:

// Dictionary<TKey, TValue> - возвращает конкретный struct:public Dictionary<TKey, TValue>.Enumerator GetEnumerator() // SortedList<TKey, TValue> - возвращает интерфейс:public IEnumerator<KeyValuePair<TKey, TValue>> GetEnumerator()

Внутри SortedList энумератор тоже структура (когда-то, еще после .NET Framework, его переделали из класса в структуру именно ради экономии). Но публичный метод отдает его через интерфейс — и структура боксится прямо на выходе. foreach по типу переменной SortedList находит именно этот метод. Итог: каждый foreach по SortedList — гарантированный боксинг, и никакая структура внутри не спасает.

Автор issue проверил и это: если поменять возвращаемый тип на конкретный Enumerator — аллокация уходит, а сам GetEnumerator по его замерам становится минимум вдвое быстрее. Он же нашел ту же болячку в ReadOnlyDictionary и еще нескольких коллекциях.

Кстати, на Хабре этот факт уже всплывал — но именно как загадка. В комментариях к статье про Dictionary и SortedDictionary (habr.com/ru/articles/784852/comments) юзер vvdev, гоняя свои бенчмарки, заметил: SortedList выделяет память в куче при каждом вызове GetEnumerator, константные 48 байтов — и честно добавил, что не смотрел, что именно там выделяется.

Вот эти 48 байтов — это и есть боксированный энумератор: заголовок объекта плюс поля структуры (точный размер зависит от типов ключа и значения). То есть на эти 48 байтов уже натыкались, но что это и откуда — так и осталось без ответа. Сейчас разберемся.

Почему Microsoft просто не поменяет одну строчку?

Вот тут самое интересное. Отвечал emilsteen в треде сам Стивен Тауб из команды .NET. Почему энумератор аллоцируется, он объяснил одним словом: Boxing. А на предложение поменять возвращаемый тип ответил: это ломающее изменение (breaking change) — возвращаемый тип входит в сигнатуру метода, и весь уже скомпилированный чужой код, который делает foreach по SortedList, сломается.

Issue закрыли как answered: по API все работает как задумано, просто задумано было неудачно, и теперь это навсегда. Ровно с той же дилеммой, кстати, столкнулись в Google Protobuf (github.com/protocolbuffers/protobuf/issues/13503) — у них коллекции боксят энумераторы по той же причине, и там тоже пришли к выводу: поменять сигнатуру нельзя, можно только добавить рядом новый метод с другим именем.

Мораль первой истории простая: вся разница между «ноль аллокаций» и «аллокация на каждый foreach» — это возвращаемый тип у GetEnumerator. Ошиблись в нем даже авторы стандартной библиотеки, а исправить уже нельзя — сигнатуру публичного метода не поменяешь. Теперь проверим цифрами.

[MemoryDiagnoser(false)][SimpleJob(RuntimeMoniker.Net80)][SimpleJob(RuntimeMoniker.Net90)][SimpleJob(RuntimeMoniker.Net10_0, baseline: true)]public class SortedListVsDictionary{    private readonly SortedList<int, int> _sortedList = new();    private readonly Dictionary<int, int> _dictionary = new();    // 15 элементов - как у автора issue #81128, он мерял ровно свой продовый размер    [GlobalSetup]    public void Setup()    {        for (int i = 0; i < 15; i++)        {            _sortedList.Add(i, i);            _dictionary.Add(i, i);        }    }    [Benchmark(Baseline = true)]    public int Dictionary_Foreach()    {        int sum = 0;        foreach (KeyValuePair<int, int> pair in _dictionary)        {            sum += pair.Value;        }        return sum;    }    [Benchmark]    public int SortedList_Foreach()    {        int sum = 0;        foreach (KeyValuePair<int, int> pair in _sortedList)        {            sum += pair.Value;        }        return sum;    }    // Контрольный выстрел: тот же Dictionary, но через интерфейс.    // Аллокация возвращается, потому что энумератор уезжает через IEnumerable.    // Это тот же эффект, что у SortedList, только мы его создали сами.    [Benchmark]    public int Dictionary_AsIEnumerable_Foreach()    {        int sum = 0;        IEnumerable<KeyValuePair<int, int>> pairs = _dictionary;        foreach (KeyValuePair<int, int> pair in pairs)        {            sum += pair.Value;        }        return sum;    }  }

Результаты:

Смотрим на .net 8 и .net 9: SortedList_Foreach — 48 байтов на каждый foreach, Dictionary_Foreach — прочерк. И обратите внимание: это ровно те же 48 байтов из хабр-комментария, о котором я писал выше — теперь мы знаем, что это за байты: боксированный struct-энумератор (заголовок объекта плюс поля структуры). Контрольный Dictionary_AsIEnumerable_Foreach тоже показал 48 B — то есть мы руками превратили Dictionary в SortedList одним приведением типа, как и обещала теория.

А теперь .net 10 — и интрига разрешилась: все три строчки по нулям. Escape analysis дотянулся и до SortedList: JIT заинлайнил GetEnumerator, увидел, что боксированный энумератор не покидает метод, и разместил его на стеке. Причем не только память — время: 12.18 ns против 37.14 ns на .net 8, в три раза быстрее без единой измененной строчки кода.

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

Отмечу тот факт, что смотреть тут надо в первую очередь на колонку Allocated, а не на время: вся история — про память и давление на GC, и ноль против ненуля — это диагноз. А теперь проверим, что это не особенность одной машины. SortedList_Foreach на всех четырех:

Картина одинаковая везде: 48 байтов на .net 8/9 и ноль на .net 10 — на трех разных сервисных сборках десятки (10.0.1, 10.0.5, 10.0.9) и на разном железе.

Тут я удивился, но не десятке, а девятке. Посмотрите на Dictionary_AsIEnumerable_Foreach: на .net 9 он в 2.4 раза медленнее, чем тот же код на .net 8. Сначала я списал это на кривой прогон, но нет — эффект воспроизвелся на всех четырех машинах и на трех разных версиях .NET 9 (9.0.5, 9.0.15, 9.0.17):

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

История вторая: .NET 10 заходит с другой стороны

Итак, чинить сигнатуры в API нельзя. Но в .NET 10 команда рантайма пошла другим путем: раз нельзя убрать боксинг из кода, пусть его убирает JIT-компилятор на лету. Это называется деабстракция (de-abstraction), и это официально одно из главных направлений релиза.

Здесь работают два механизма:

• Escape analysis (анализ убегания). JIT смотрит на объект и спрашивает: этот объект покидает метод? Сохраняется в поле, возвращается наружу, уходит в неизвестный чужой код? Если нет — значит, время его жизни ограничено методом, и объект можно не выделять на куче, а разместить прямо на стеке. Стек освобождается сам при выходе из метода, GC вообще не в курсе, что объект существовал.

• PGO и guarded devirtualization. Рантайм какое-то время наблюдает за методом и собирает профиль: какой конкретный тип реально приходит в переменную IEnumerable. Если в 99% случаев это int[] — JIT генерирует отдельную быструю ветку кода именно под int[], где все вызовы энумератора уже не виртуальные, инлайнятся, и энумератор можно стек-аллоцировать. На случай, если придет что-то другое, остается запасная медленная ветка (потому и guarded — с охраной).

Пруфы. Официальный план деабстракции — issue №108913, там прямым текстом: благодаря PR №108153 мы можем девиртуализовать и заинлайнить конструктор энумератора и вызовы на нем, а в ряде случаев даже стек-аллоцировать энумератор — и в таблице бенчмарков .NET 10 аллокаций больше нет.

То же самое — в официальной документации What’s new in .NET 10 runtime и в огромном посте Стивена Тауба Performance Improvements in .NET 10. Тауб отдельно пишет: с прогрессом .NET 10 это происходит очень часто для массивов и List<T>, а интерфейс IEnumerator<T> даже пометили как [Intrinsic], чтобы JIT мог рассуждать о нем напрямую.

Как одна оптимизация мешала другой: пустой массив

А теперь самое интересное из issue №108913 — то, ради чего отчасти и писалась эта статья. Когда команда JIT взялась стек-аллоцировать энумераторы массивов, она уперлась в… собственную старую оптимизацию.

Дело вот в чем. Энумератор массива — это класс SZGenericArrayEnumerator<T>. И в его создании давным-давно сделали экономию: для пустого массива новый энумератор не создается, а возвращается один общий статический экземпляр (синглтон). Логика железная — зачем плодить объекты ради перебора нуля элементов.

Но для escape analysis это подстава: теперь в точке, где крутится цикл, JIT не может сказать, какой именно объект он итерирует — свежесозданный (его можно на стек) или тот самый общий синглтон (его на стек нельзя, он общий на весь процесс). Неоднозначность — и анализ пасует. В issue это описано прямым текстом: из-за оптимизации для пустых массивов в точках использования энумератора возникает неопределенность, какой объект итерирует.

Анти-аллокационный трюк десятилетней давности блокировал анти-аллокационную оптимизацию 2025 года!

Пришлось учить JIT разруливать оба варианта (это и называется conditional escape analysis — стек-аллокация с проверкой условия на входе). По-моему, это лучшая иллюстрация того, почему в перформансе нельзя ничего принимать на веру: даже оптимизации внутри самого рантайма могут конфликтовать друг с другом.

[MemoryDiagnoser(false)][SimpleJob(RuntimeMoniker.Net80)][SimpleJob(RuntimeMoniker.Net90)][SimpleJob(RuntimeMoniker.Net10_0, baseline: true)]public class ArrayDeabstraction{    private readonly int[] _array = Enumerable.Range(0, 512).ToArray();    private readonly int[] _empty = [];    // Эталон: foreach по массиву напрямую. Компилятор разворачивает в for по индексу.    // Ноль аллокаций на любом рантайме, интерфейсы не участвуют вообще.    [Benchmark(Baseline = true)]    public int Array_Direct()    {        int sum = 0;        foreach (int i in _array)        {            sum += i;        }        return sum;    }    // Главный подопытный: тот же массив, но через переменную интерфейсного типа.    // Тут foreach обязан получить энумератор через IEnumerable<int>.GetEnumerator(),    // а это объект на куче. Смотрим, на каком рантайме колонка Allocated обнулится.    [Benchmark]    public int Array_AsIEnumerable()    {        int sum = 0;        IEnumerable<int> items = _array;        foreach (int i in items)        {            sum += i;        }        return sum;    }    // Через невиртуальный метод-хелпер, как в примере Стивена Тауба из блога    // "Performance Improvements in .NET 10": PGO видит, что сюда всегда приходит int[],    // делает специализированную ветку и стек-аллоцирует энумератор.    [Benchmark]    public int Array_ViaHelper() => Sum(_array);    [MethodImpl(MethodImplOptions.NoInlining)]    private static int Sum(IEnumerable<int> values)    {        int sum = 0;        foreach (int i in values)        {            sum += i;        }        return sum;    }    // Пустой массив через интерфейс: сюда прилетает синглтон-энумератор.    // Аллокаций нет и не было (синглтон!), но именно этот случай исторически    // ломал escape analysis для НЕпустых массивов - см. issue 108913.    [Benchmark]    public int EmptyArray_AsIEnumerable()    {        int sum = 0;        IEnumerable<int> items = _empty;        foreach (int i in items)        {            sum += i;        }        return sum;    }  }

Результаты:

Тут все сбылось буквально. На .net 8 и .net 9 массив через интерфейс — это 32 байта боксинга на каждый вызов и просадка в 4.4–5.2 раза по времени. На .net 10 — прочерк в Allocated, а время 152.9 ns: интерфейсный цикл стал всего на 17% медленнее прямого — при том же самом коде.

Это и есть деабстракция в действии, и это тот самый ответ, почему нельзя верить статьям с выводами уровня «foreach по IEnumerable всегда боксит»: на .net 8 — да, на .net 10 — уже нет. Сводка по всем машинам (Array_AsIEnumerable):

Отдельно повеселила машина №1: на Ryzen интерфейсный вариант на .net 10 (116.2 ns) обогнал даже прямой foreach по массиву (124.9 ns). Нет, интерфейсы не стали быстрее массивов — после всех оптимизаций JIT генерирует для обоих вариантов практически одинаковый цикл, и кто из двух окажется на пару процентов быстрее, решают уже случайные мелочи вроде того, как код лег в памяти. Но сам факт показателен: раньше интерфейс проигрывал в четыре раза, теперь эти два варианта почти неотличимы.

Попутно два наблюдения по таблице:

• .net 9 в этом тесте медленнее .net 8 (682 против 582 ns) — и это уже второй случай, где девятка проседает относительно восьмерки. Прогресс между версиями не обязан быть монотонным: эвристики JIT перекраиваются, и отдельные сценарии могут временно деградировать.

• EmptyArray_AsIEnumerable на .net 10 — 0.0003 ns. Это не опечатка и не сломанный замер: JIT понял, что перебор пустого массива не делает ничего, и выкинул весь цикл целиком — метод схлопнулся до «верни ноль». Синглтон-энумератор, который мешал escape analysis, в итоге сам был съеден оптимизатором вместе с циклом.

Смотрим машинный код

Колонке Allocated можно верить, но раз уж мы охотимся на то, чего нет в исходниках, финальный пруф — в машинном коде. JIT умеет показывать сгенерированный код через переменную окружения, без каких-либо инструментов. Чтобы вывод был чистым, я вынес тот же foreach по IEnumerable<int> в отдельную мини-программу (метод SumOverInterface, код в репозитории) и снял листинги на машине №2:

dotnet build -c Releaseset DOTNET_JitDisasm=*SumOverInterface*bin\Release\net8.0\DisasmProof.exe  > disasm_net8.txt  2>&1bin\Release\net10.0\DisasmProof.exe > disasm_net10.txt 2>&1

JIT печатает метод несколько раз — по мере прогрева он перекомпилирует его от простого tier 0 до оптимизированного tier 1. Нас интересуют финальные tier 1-версии. Сначала .net 8 (листинги сокращены до смысловых строк):

; .NET 8, Tier1, optimized using Dynamic PGO   ; всего 460 байт кода        call     [r11]IEnumerable`1[int]:GetEnumerator()       mov      gword ptr [rbp-0x30], rcx   ; ссылка на объект-энумератор В КУЧЕ G_M000_IG06:                                ; тело цикла, каждая итерация:       cmp      rsi, rdi                    ; тип энумератора все еще тот, что угадали?       jne      SHORT G_M000_IG10           ; нет - уходим на виртуальные вызовы       ...G_M000_IG10:       call     [r11]IEnumerator:MoveNext() ; виртуальный вызов (медленный путь)       ...G_M000_IG24:       call     [r11]IDisposable:Dispose()  ; виртуальный Dispose в конце

Что тут происходит. Восьмерка с включенным PGO уже не так проста: она угадала конкретный тип энумератора и заинлайнила его MoveNext и Current (это guarded devirtualization). Но два момента никуда не делись: сам объект энумератора создается в куче внутри невиртуализованного вызова GetEnumerator — это и есть те 32 байта из таблиц (gword в листинге — ссылка на объект в куче, которую отслеживает GC), и проверка типа повторяется на каждой итерации цикла.

Теперь .net 10:

; .NET 10, Tier1                               ; всего 193 байта кода        mov      rax, 0x7FF9F36CB188         ; method table типа int[]       cmp      qword ptr [rcx], rax        ; проверка типа ОДИН раз, на входе       jne      SHORT G_M000_IG07           ; не массив - запасной общий путь       mov      eax, dword ptr [rcx+0x08]   ; длина массива G_M000_IG03:                                ; весь foreach целиком:       add      ebx, dword ptr [rcx+4*r8+0x10]  ; читаем элемент прямо из массива       inc      edx       cmp      edx, eax       jb       SHORT G_M000_IG03

Вот ради этих строчек все и затевалось. GetEnumerator на быстром пути не вызывается вообще. Энумератора нет — ни в куче, ни на стеке: JIT его полностью выкинул и переписал foreach в индексный проход по массиву, тот самый, который for.

Проверка типа выполняется один раз на входе в метод, а не на каждой итерации. Размер кода — 193 байта против 460. Аллокация исчезла не потому, что ее куда-то спрятали: ее физически нет в машинном коде.

История третья: оптимизация, которая исчезает с размером списка

Если бы на этом все закончилось, вывод был бы простой: обновляйтесь на .NET 10 и забудьте про боксинг энумераторов. Но нет. У этой оптимизации есть граница, и она задокументирована самим же Таубом в том же посте про .NET 10. Причем проходит она в неожиданном месте — по размеру коллекции.

Тауб описывает два эффекта:

• Редкая ветка. Внутри MoveNext у List<T> есть запасной метод MoveNextRare — он вызывается один раз в самом конце перебора, чтобы завершить итерацию. То есть на список из 10 элементов приходится 10 обычных шагов и один вызов MoveNextRare, а на список из миллиона — миллион шагов и все равно один MoveNextRare.

  Дальше вступает профилировка. JIT решает, какие методы заинлайнить, глядя на статистику вызовов: часто вызывается — инлайним, почти не вызывается — не тратим на него место. На коротком списке MoveNextRare срабатывает каждый десятый вызов — для JIT это нормальная рабочая ветка, он ее инлайнит, весь энумератор целиком разбирается по косточкам и ложится на стек.

  На длинном списке тот же MoveNextRare — один вызов на миллион, по статистике им можно пренебречь, и JIT его не инлайнит. А вот теперь ловушка: раз метод не заинлайнен, энумератор нужно передать в него как обычный объект — то есть отдать наружу. Для escape analysis «отдать наружу» значит «объект убегает из метода», и класть его на стек больше нельзя. Стек-аллокация срывается — из-за метода, который вызовется один раз.

• OSR против PGO. Если метод крутит очень длинный цикл, рантайм не ждет его окончания, а перекомпилирует метод прямо посреди выполнения — это называется OSR (On-Stack Replacement). Проблема: OSR-версии методов не собирают PGO-инструментацию. А без профиля для хвоста метода — того места, где вызывается Dispose энумератора — JIT не может сделать guarded devirtualization, и вся цепочка оптимизаций рассыпается.

Итог по описанию должен быть парадоксальный: один и тот же foreach по IEnumerable<int> на .NET 10 дает 0 B на маленьком списке и снова начинает аллоцировать на большом. Звучит как отличный материал для бенчмарка — берем Params на три размера и идем ловить обрыв.

[MemoryDiagnoser(false)][SimpleJob(RuntimeMoniker.Net80)][SimpleJob(RuntimeMoniker.Net90)][SimpleJob(RuntimeMoniker.Net10_0, baseline: true)]public class ListSizeCliff{    [Params(10, 1_000, 1_000_000)]    public int Size { get; set; }    private List<int> _list = null!;    [GlobalSetup]    public void Setup()    {        _list = Enumerable.Range(0, Size).ToList();    }    // Эталон: foreach по List напрямую - struct-энумератор, ноль аллокаций везде.    [Benchmark(Baseline = true)]    public long List_Direct()    {        long sum = 0;        foreach (int i in _list)        {            sum += i;        }        return sum;    }    // Подопытный: тот же список через интерфейс.    // .NET 8/9: 40 B на вызов на любом размере.    // .NET 10: ожидаем 0 B на маленьких размерах и возврат аллокации на большом.    [Benchmark]    public long List_AsIEnumerable()    {        long sum = 0;        IEnumerable<int> items = _list;        foreach (int i in items)        {            sum += i;        }        return sum;    }    // Тот же сценарий, но через отдельный метод, чтобы PGO собирал профиль    // именно по этому колл-сайту (так устроен пример из блога .NET).    [Benchmark]    public long List_ViaHelper() => Sum(_list);    [MethodImpl(MethodImplOptions.NoInlining)]    private static long Sum(IEnumerable<int> values)    {        long sum = 0;        foreach (int i in values)        {            sum += i;        }        return sum;    }  }

Результаты (для компактности сгруппировал по размеру):

Сначала подтвержденная часть. На .net 8 и .net 9 картина железная: 40 байтов на боксинг энумератора на любом размере и трехкратная просадка по времени. На .net 10 на маленьких размерах — нули и время вплотную к прямому перебору (ratio 1.02 на тысяче элементов — интерфейс стал практически бесплатным).

Теперь главное — миллион элементов. Обрыв… не случился. Прочерк в Allocated, ratio 1.01. Я ждал возврата 40 байтов, перечитал пост Тауба, перепроверил цифры — обрыва нет. Признаюсь, такого я не ожидал. Первая мысль была: может, дело в конкретной сборке рантайма? Проверяем на всех машинах, List_AsIEnumerable на миллионе:

Нет. Три разные сервисные сборки .NET 10 — 10.0.1, 10.0.5 и 10.0.9 — и на всех нули даже на миллионе элементов. Версия рантайма как подозреваемый отпадает.

Разгадка, как я ее понимаю, в условиях замера:

• BenchmarkDotNet перед измерением вызывает метод много раз. Метод успевает полностью перекомпилироваться в tier 1 с собранным профилем — и вся цепочка девиртуализаций отрабатывает независимо от размера списка.

• Эффекты из поста Тауба бьют по другому сценарию: OSR-компиляция включается, когда метод вызвали один-два раза и внутри крутится огромный цикл — рантайм перекомпилирует его прямо посреди выполнения, и у этой OSR-версии профиля нет. В проде это типичный случай: разовая обработка большого файла, миграция, батч при старте сервиса. Бенчмарк такой сценарий физически не меряет — он всегда про горячий, много раз вызванный код.

• Пост Тауба писался по превью-сборкам, а релизные эвристики явно дотянули: три разные сервисные версии .NET 10 на четырех машинах дали одинаковые нули. Значит, дело не в конкретной сборке, а в самом сценарии замера.

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

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

Выводы

• foreach по конкретному типу (List<T>, массив, Dictionary) — бесплатный. foreach по переменной типа IEnumerable<T> — аллокация энумератора, на .net 8/9 всегда, на .net 10 — как повезет с профилем и размером.

• Если пишете свою коллекцию — из публичного GetEnumerator возвращайте конкретный struct, интерфейсные версии делайте явной реализацией. Вернете интерфейс — получите свой SortedList с аллокацией на каждый foreach, и исправить это потом будет нельзя.

• SortedList, ReadOnlyDictionary и часть других коллекций BCL аллоцируют на каждый foreach на .net 8/9. Если такой foreach у вас на горячем пути — обходите по индексу или берите другую коллекцию.

• На .NET 10 не спешите переписывать код ради боксинга энумераторов — сначала померяйте: возможно, JIT уже все убрал. Но помните, что бенчмарк меряет прогретый код: у разово вызванного метода с огромным циклом (OSR-путь) оптимизация по данным команды .NET может срываться, хотя в моих прогонах на 10.0.9 обрыв не воспроизвелся даже на миллионе элементов.

• Колонка Allocated в MemoryDiagnoser — первое, на что стоит смотреть. Ноль против ненуля важнее любых наносекунд.

Код из статьи

• HiddenEnumerators — бенчмарки: три класса, мульти-таргет на net8.0/net9.0/net10.0, сводка и графики после прогона

• DisasmProof — снятие машинного кода: программа, snap.bat и полные листинги disasm_net8.txt / disasm_net10.txt, из которых взяты фрагменты в статье

Ссылки

• Issue №81128 — SortedList Enumerator is allocated on the heap

• Issue №108913 — JIT: De-abstraction in .NET 10 (план деабстракции, синглтон пустого энумератора)

• PR №108153 — девиртуализация интерфейсных методов массивов

• Issue №104936 — Stack Allocation Enhancements (трекинг escape analysis)

• What’s new in .NET 10 runtime — официальная документация

• Stephen Toub — Performance Improvements in .NET 10 (разделы про deabstraction, OSR и PGO)

• Protobuf issue №13503 — та же дилемма со сменой сигнатуры GetEnumerator

• Issue №4505, открыт в 2015 — этой проблеме официально больше десяти лет

• Комментарии к статье про Dictionary и SortedDictionary на Хабре — те самые замеченные, но не объясненные 48 байтов у SortedList

Всем удачи и до новых встреч!

PS: все таблицы в статье — реальные прогоны на четырех машинах из таблицы в начале. На вашем железе абсолютные цифры будут свои — важны не наносекунды, а нули против ненулей в Allocated. Эвристики JIT меняются между сервисными релизами, так что если у вас картина другая (особенно если поймаете обрыв из третьей истории или найдете причину регрессии .net 9 из первой) — пишите в комментариях с версией рантайма, это самое интересное.