Библиотека шарписта | C#, F#, .NET, ASP.NET: “⚙️ yield return не бесплатный Итераторы выглядят просто, но работают и…”

⚙️ yield return не бесплатный

Итераторы выглядят просто, но работают иначе:


IEnumerable<int> GetIds()
{
    foreach (var item in _items)
        yield return item.Id;
}

Читается как обычный цикл. Но компилятор превращает такой метод в конечный автомат со вспомогательными классами и состоянием. Именно поэтому итераторы такие выразительные — но и именно поэтому они не бесплатны.

❓ Где это становится проблемой

На большинстве путей yield return это правильный выбор. Код чище, API удобнее, читаемость выше.

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

❓ Что делать на критичных участках

Если профилировщик показал, что итератор узкое место, есть несколько альтернатив.

🟡 Заполнение буфера, переданного вызывающей стороной:


void FillIds(Span<int> buffer)
{
    for (int i = 0; i < _items.Count; i++)
        buffer[i] = _items[i].Id;
}

🟡 Возврат конкретной коллекции:


List<int> GetIds()
{
    var result = new List<int>(_items.Count);
    foreach (var item in _items)
        result.Add(item.Id);
    return result;
}

🟡 Прямой цикл внутри горячего кода без промежуточных перечислений:


for (int i = 0; i < _items.Count; i++)
    Process(_items[i].Id);

yield return стоит использовать тогда, когда он делает API лучше и код понятнее. Но не стоит считать его нулевым по стоимости. Если участок горячий, то сначала замерьте, потом решайте.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#il_люминатор