Краткий ответ

Генератор вычисляет элементы лениво: очередной элемент создаётся только в момент запроса, поэтому весь результат не обязан одновременно находиться в памяти. Это снижает пиковое потребление памяти при последовательной обработке, если потребитель тоже обрабатывает элементы по одному и промежуточные данные не накапливаются.

Генератор не уменьшает размер самих объектов и не гарантирует экономию памяти при последующей материализации результата в список, словарь или другую коллекцию.

Исторический контекст

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

Итераторы и генераторы в Python решают эту задачу за счёт протокола последовательного получения элементов. Генератор хранит только состояние вычисления и данные, необходимые для продолжения работы, вместо хранения полного результата.

Постановка проблемы

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

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

Подробное решение

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

Например, в следующем сравнении генератор передаёт элементы функции sum по одному:

n = 10_000_000

values = [value * 2 for value in range(n)]
list_total = sum(values)

generator_total = sum(value * 2 for value in range(n))

В первом случае список хранит все вычисленные значения до начала или завершения суммирования. Во втором случае промежуточное значение создаётся, передаётся в sum, после чего становится недостижимым; одновременно не требуется хранить весь набор.

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

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

Основной компромисс — между памятью и повторным использованием. Генератор обычно одноразовый: после исчерпания его нельзя заново обойти без повторного вычисления. Он также может быть медленнее из-за большого числа переключений между шагами и не поддерживает произвольный доступ по индексу.

Ситуация из практики

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

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

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

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

Что кандидаты часто упускают

Почему генератор не гарантирует константное потребление памяти?

Генератор уменьшает память, необходимую для хранения уже неиспользуемых элементов, но не контролирует память потребителя и источника. Потребитель может сохранять результаты, а источник — держать большой внутренний буфер. Кроме того, локальные переменные генератора могут удерживать ссылки на крупные объекты между выдачами элементов.
Что произойдёт, если передать генератор операции, которой нужны все элементы сразу?

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

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