When is calling gc.disable() in a production Python service defensible, and what breaks?

**What it actually turns off.** `gc.disable()` stops *automatic* runs of the tracing cycle collector. Reference counting is untouched and keeps freeing objects the instant their last reference disappears, which covers the overwhelming majority of allocations in normal code. Explicit `gc.collect()` still works after `gc.disable()`; only the automatic trigger is gone. `gc.isenabled()` reports the current state. This is the single most misunderstood point: disabling the collector does not disable garbage collection in Python, it disables the part that handles cycles. **Three defensible uses.** *A short-lived process.* A batch job, a CLI tool or a one-shot importer that runs for a bounded time and exits can trade memory for CPU outright. Cyclic garbage accumulates, but the process dies before that matters, and the collector's passes over a growing heap were pure overhead. *A bounded latency window.* Code with a hard tail-latency budget can disable collection around the critical section and re-enable afterwards, moving the pause somewhere it does not hurt. The discipline is that this is bounded and paired: disable, do the work, enable, and usually collect at the safe point after. *A pre-forking server.* This is the strongest case and the most Python-specific. After the parent finishes loading code and building its startup structures, `gc.collect()` compacts the picture, and `gc.freeze()` then moves every currently tracked object into a permanent generation the collector ignores from then on. Its documented purpose is exactly this: make the process copy-on-write friendly before a POSIX fork. Without it, the first collection in each forked child walks those long-lived parent objects and writes to their headers, which dirties the shared pages and forces the kernel to copy memory the workers were supposed to share. `gc.get_freeze_count()` reports how many objects are frozen, and `gc.unfreeze()` puts them back. ```python import gc gc.collect() gc.freeze() # startup objects move to the permanent generation print(gc.get_freeze_count()) ``` **What breaks.** Cyclic garbage is the obvious cost: with automatic passes gone, every cycle the code creates stays resident until someone calls `gc.collect()`. In cycle-heavy code — object graphs with back-pointers, retained exceptions holding tracebacks and frames, callback registries — that is unbounded growth on a long-running process. Finalization is delayed with it, so anything relying on a cyclic object's cleanup waits indefinitely. The setting is also process-wide and invisible. Your service imports libraries that were written expecting a collector; disabling it globally changes their memory behaviour without them or their authors knowing. Some libraries re-enable it, so the state is not even reliably yours. If you disable, own it explicitly: call `gc.collect()` at a natural quiet point — between batches, between requests, on a scheduled tick — and treat that call as load-bearing code with a comment saying why. **Cheaper alternatives to reach for first.** Raising the first collection threshold with `gc.set_threshold()` reduces pass frequency without giving up automatic collection entirely, and is reversible and measurable. Freezing after startup with `gc.freeze()` removes the long-lived graph from every future pass while leaving new allocations collected normally — often the whole win with none of the risk. And best of all, creating fewer cycles: dropping a back-pointer or holding it as a non-owning reference means the counter frees those objects immediately and the collector never has to consider them. **How to justify it in an interview.** Do not present `gc.disable()` as a performance tip. Present it as a bounded, measured decision: here is the collector cost measured with `gc.get_stats()` or a `gc.callbacks` hook, here is the process lifetime that makes the accumulation acceptable, here is where the explicit collection happens, and here is the memory ceiling we verified afterwards. A candidate who says 'we disabled the GC and it got faster' without those four things is describing a leak they have not found yet.