gc.collect Cost Empty vs Cycles: Localhost Lab

Intro — what this post promises

Cost of gc.collect() when the heap is empty vs when it holds cyclic garbage. This lab reports collect latency, collects/s, and objects reclaimed on Linux localhost.

Related links:

• sqlite3 vs shelve localhost lab
• fractions vs float localhost lab
• math fsum vs sum localhost lab
• itertools batched vs chunk localhost lab
• exitstack vs nested with localhost lab
• xml etree vs json localhost lab
• logging formatter vs fstring localhost lab
• copy copy vs dict copy localhost lab

Lab honesty (1 Oct 2026 IST): Python 3.13.5. Affiliates: 0. GC stayed enabled so cycles are tracked (disabled-GC setups under-count reclaim).

Verdict up front (50000 cycle pairs): empty full collect ~0.709 ms (~1411 collects/s); with cycles ~12.587 ms reclaiming ~100006 objects.

Arms

Seven rounds, p50. Each with-cycles arm rebuilds garbage after a clean collect.

Lab topology

n_cycle_pairs=50000 · 7 rounds · p50
metrics: p50_s, collects/s, p50_collected

Script: lab-evidence/129-gc-collect-cost/results/run_lab.py.

Lead table

Gen0 is not enough

After building cycles, gen0 reclaimed only ~1964 objects; the following full collect took ~12.309 ms and reclaimed ~98042. Calling gc.collect(0) in a request path can look “cheap” while leaving cyclic junk behind.

Reading it for SRE work

• Empty full collect is cheap here (~0.709 ms) — do not fear an occasional manual collect in a maintenance task.
• Cyclic graphs (caches with parent/child links) make full collect ~17.8× slower than empty on this run.
• Prefer breaking cycles (weakref, explicit clear) over hoping gen0 saves you.
• Pair with RSS/tracemalloc labs if you later measure allocator pressure.

Allocation context

Building a plain 50000-int list (no cycles) ran at ~80686416 objs/s. That arm is not a collect — it shows allocation itself is far cheaper than a full collect over ~100006 cyclic objects.

Operational takeaway for latency budgets

A maintenance gc.collect() on a quiet process cost ~0.709 ms here. The same call after 50000 orphaned cycles jumped to ~12.587 ms. Put cycle-prone structures behind weakrefs or explicit teardown in long-lived workers; reserve full collects for controlled windows, not per-request cleanup.

Pitfalls

• Disabling GC while creating objects, then wondering why collect() reclaims 0.
• Using only gc.collect(0) as a “GC health check”.
• Comparing collect latency across machines without stating object graph shape.
• Forcing full collect in the hot path without a latency budget.

Reproduce

python3 lab-evidence/129-gc-collect-cost/results/run_lab.py

Evidence: summary.json, summary.txt.

Limits

One Linux box, CPython cyclic GC only. Not pymalloc arena tuning, not Go/Java collectors.

Manual collects belong in runbooks with a stated latency budget — not as a silent fix for “memory looked high” without graph evidence.

Takeaway

Empty gc.collect() ~0.709 ms; with 50000 cycle pairs ~12.587 ms reclaiming ~100006 objects. Prefer breaking cycles; do not trust gen0 alone for cyclic heaps.