MEASUREMENT

bench/gc/practice.py

The script that produced the numbers in the article, and the record of the run. The file is read from the repository at build time — this is the code that was run, not a copy of it.

Cited in

/en/interview/python/garbage-collection

How to run it

python3.11 bench/gc/alive.py
python3.12 bench/gc/alive.py
python3.13 bench/gc/alive.py
python3.14 bench/gc/alive.py

python3.13 bench/gc/pause.py

python3.11 bench/gc/freethreaded.py    # и 3.12, 3.13, 3.14
python3.13t bench/gc/freethreaded.py   # сборки без GIL
python3.14t bench/gc/freethreaded.py
python3.13t bench/gc/alive.py
python3.14t bench/gc/alive.py

The run below is recorded in Russian. It is a lab record, kept in the language it was written in; the numbers, the tables and the code read the same either way.

Record of the run

Замеры для урока «Сборка мусора»

Скрипт	Что делает
`alive.py`	наблюдения без времени: жив ли объект без цикла и в цикле, исключение в локальной переменной и в атрибуте, `lru_cache` на методе, связанный метод в списке подписчиков, `__del__` в цикле
`pause.py`	время полной сборки `gc.collect()` при 10 тысячах, 100 тысячах и миллионе живых списков без мусора, и то же после `gc.freeze()`
`practice.py`	источник ответов двух практических задач урока
`freethreaded.py`	сборка без GIL против обычной: экземпляр в одном потоке, функция уровня модуля, последняя ссылка в чужом потоке, `gc.freeze()` на миллионе живых списков

python3.11 bench/gc/alive.py
python3.12 bench/gc/alive.py
python3.13 bench/gc/alive.py
python3.14 bench/gc/alive.py

python3.13 bench/gc/pause.py

python3.11 bench/gc/freethreaded.py    # и 3.12, 3.13, 3.14
python3.13t bench/gc/freethreaded.py   # сборки без GIL
python3.14t bench/gc/freethreaded.py
python3.13t bench/gc/alive.py
python3.14t bench/gc/alive.py

Записи в runs/: без суффикса — 3.13.7 с GIL, остальные версии — с суффиксом; t в суффиксе — сборка без GIL (3.13t, 3.14t).

Как проверяется «жив ли объект»

Слабой ссылкой: она не увеличивает счётчик ссылок, а после смерти объекта возвращает None. Так проверка не держит то, что проверяет.

Сборщик циклов в alive.py выключен на время опытов 1–5. Иначе он мог бы сработать сам между двумя строками, и «жив до gc.collect()» превратилось бы в «жив, пока повезёт». gc.collect() при выключенном сборщике работает — gc.disable() отключает только автоматический запуск по порогам.

Ошибка, оставленная в истории

Первая редакция alive.py печатала вывод, написанный до прогона. В сюжете «исключение в атрибуте» после svc.last_error = None стояла подпись «в цикле с кадром, ждёт сборщика». Прогон показал, что объект умер сразу: имя e интерпретатор уже удалил, кадр на исключение не ссылается, и убранный атрибут опускает счётчик исключения до нуля. Цикл из справочника — кадр → исключение → трассировка → кадр — получается, только если исключение положить в локальную переменную той же функции; тогда после выхода из функции группа недостижима и ждёт сборщика.

Вторая редакция урока назвала случай с атрибутом «цепочкой, а не циклом», и это тоже было неточно: кадр ссылается на глобальные переменные модуля, а через них — снова на svc, так что цикл там формально есть. Различие, которое действительно показывает прогон, другое: достижимо ли всё это от живого объекта. Если да — gc.collect() объект не трогает (это теперь напечатано отдельной строкой в разделах 3–5), а убранная ссылка освобождает его сразу. Если нет — объект ждёт сборщика.

Что получилось

Все шесть опытов alive.py дают одинаковый вывод на 3.11–3.14 (кроме строки с версией и порогами: (700, 10, 10) на 3.11.15 и 3.12.3, (2000, 10, 10) на 3.13.7 и 3.14.7).

Полная сборка платит за живые объекты. На 3.13.7 без единого мусорного объекта: 0,75 мс при 10 тысячах живых списков, 3,57 мс при 100 тысячах, 39,88 мс при миллионе — порядка 30–40 нс на живой объект. На других версиях то же с точностью до шума машины.

gc.freeze() убирает живое из обхода: тот же миллион, 38545,7 мкс до и 0,3 мкс после.

Сборка без GIL (добавлено 02.10.2026)

Внешний аудит указал, что урок помечен 3.13 и 3.14 и при этом говорит про одну сборку CPython, хотя с 3.13 их две. Проверено запуском на 3.13.7 и 3.14.7 без GIL (sys.version: «experimental free-threading build» у 3.13.7 и «free-threading build» у 3.14.7).

Что совпало. Обычный экземпляр, созданный и отпущенный одним потоком, умирает на строке del и там. alive.py на сборках без GIL даёт тот же вывод, что с GIL, кроме одной строки: в разделе 6 gc.collect() вернул 3, а не 2. Третий объект — функция тела класса Finalized (видно через gc.DEBUG_SAVEALL): в обычной сборке она умирает счётчиком сразу после создания класса, без GIL — ждёт сборщика.

Что не совпало — freethreaded.py:

функция, объявленная на уровне модуля, после del жива и умирает только на gc.collect(); вложенная функция умирает сразу;
если последнюю ссылку удаляет не тот поток, что создал объект, в том потоке сразу после del объект жив: 20 из 20 на 3.13t, 19 из 20 на 3.14t — результат зависит от расписания потоков, поэтому печатается счёт. В главном потоке после join() — мёртв во всех попытках. С GIL — 0 из 20 на всех четырёх версиях;
gc.freeze() без GIL убирает из сборки не всё: на 3.14t 37,3 мс до и 23,2 мс после, на 3.13t 63,5 и 23,4 мс. С GIL после заморозки остаются доли микросекунды (0,2–0,3 мкс).

Абсолютные времена в разделе 4 не сравнимы с pause.py: куча к этому моменту устроена иначе, и на 3.13.7 с GIL сборка миллиона списков здесь заняла 86,9 мс против 39,88 мс в pause.py. Содержательно только сравнение «до и после» внутри одного прогона.

Сборщик сборки без GIL — отдельная реализация: в libpython3.14t.so строка пути исходника — Python/gc_free_threading.c, в libpython3.14.so — Python/gc.c (проверено strings).

Механизм — в PEP 703: у объекта есть поток-владелец (biased reference counting), а часть объектов считается отложенно. Дословные цитаты PEP для урока не сняты: при подготовке правки страница PEP была недоступна, и урок опирается на прогон, а не на пересказ.

Практика урока

practice.py — источник ответов двух задач, runs/practice.txt — дословная запись его прогона на 3.13.7. Вторая задача — во сколько раз дольше полная сборка при десятикратном росте числа живых объектов: 9,8 на 3.13.7, 9,8–10,3 на четырёх версиях.

Script

64 lines

"""Практика урока «Сборка мусора»: источник ответов двух задач.

Ответ задачи не сочиняется редакцией — он берётся из записи прогона этого
скрипта (`runs/practice.txt`), а сборка сверяет одно с другим
(`scripts/validate-practice.mjs`).

ЧТО ПРОВЕРЯЮТ ЗАДАЧИ. Первая — что `del` не уничтожает объект, а убирает
имя: вершины цикла живы после `del` и умирают только на `gc.collect()`.
Сборщик выключен, чтобы он не сработал сам между двумя строками печати.

Вторая — за что платит полная сборка. Мусора нет ни одного, а время всё
равно растёт — с числом ЖИВЫХ контейнеров, потому что полная сборка обходит
и их. Живых стало в десять раз больше — сборка дольше примерно во столько же.

Запускать: python3.11 / 3.12 / 3.13 / 3.14.
"""
import gc
import sys
import time
import weakref

print("PY", sys.version.split()[0])
print()
print("вывод задачи:")


class Node:
    pass


gc.disable()
a = Node()
b = Node()
a.other = b
b.other = a
r = weakref.ref(a)
del a, b
print(r() is None)
gc.collect()
print(r() is None)

gc.enable()
print()

REPEAT = 7


def best_collect():
    best = float("inf")
    for _ in range(REPEAT):
        t0 = time.perf_counter()
        gc.collect()
        best = min(best, time.perf_counter() - t0)
    return best


live = [[i] for i in range(100_000)]
t_small = best_collect()
live += [[i] for i in range(900_000)]
t_big = best_collect()
print(f"gc.collect(), 100 тысяч живых списков:  {t_small * 1e3:6.2f} мс")
print(f"gc.collect(), миллион живых списков:     {t_big * 1e3:6.2f} мс")
print(f"  живых в 10 раз больше — полная сборка дольше в {t_big / t_small:.1f} раза")