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

Временное отключение циклического сборщика мусора может ускорить код, если фаза создаёт много короткоживущих объектов, не образующих циклов, а затраты на периодические проверки GC заметны. Освобождение объектов при этом не прекращается: в CPython обычно продолжает работать подсчёт ссылок.

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

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

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

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

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

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

Без измерений отключение GC опасно: выигрыш может быть меньше стоимости ручного управления, а циклические ссылки начнут удерживать память дольше. Особенно рискованны долгие операции, пользовательские callback-функции и сложные графы объектов.

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

Отключение GC через gc.disable() отключает именно автоматические циклические коллекции, а не управление ссылками в целом. Объекты с нулевым числом ссылок по-прежнему обычно освобождаются немедленно благодаря подсчёту ссылок.

Приём оправдан, когда одновременно выполняются следующие условия:

профилирование показывает заметные затраты на GC;
рабочая фаза короткая или имеет чёткие границы;
создаваемые объекты не образуют циклов либо риск циклов исключён;
после фазы предусмотрена проверка и, при необходимости, ручной gc.collect().

Минимальный шаблон выглядит так:

import gc

def batch():
    for _ in range(100_000):
        values = [1, 2, 3]
        record = {"values": values}

batch()
gc.disable()
try:
    batch()
finally:
    gc.enable()
    gc.collect()

В этом примере отключение действует на текущий интерпретатор, а не на отдельный участок одного потока. В реальном коде сначала сравнивают время, CPU-профиль и потребление памяти с включённым GC; сам факт большого числа аллокаций ещё не доказывает, что GC является узким местом.

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

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

В ETL-сервисе пакет преобразований создавал множество временных словарей. Профилирование показало, что значимая доля CPU уходила на циклический GC, хотя архитектура преобразований не создавала циклических ссылок.

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

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

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

Означает ли отключение GC, что Python перестаёт освобождать любые объекты?

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

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

Как проверить, что отключение GC не скрывает циклическую утечку?

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

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

Почему вместо полного отключения иногда лучше изменить пороги GC?

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

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