How does gc.get_objects() with collections.Counter give a census of live objects?

### What the call actually returns `gc.get_objects()` asks the cyclic garbage collector for its tracking lists and returns them as one new list. Those lists are how the collector does its job: to find unreachable cycles it must know every object that *could* participate in one, which means every object capable of holding a reference to another object. So the result is a snapshot of the tracked heap -- lists, dicts, sets, tuples that contain non-atomic items, instances of ordinary classes, functions, frames, modules, cells, and so on. Since Python 3.8 the call also accepts an optional generation argument, so you can ask for only the youngest tracked objects; the census technique below is unchanged through 3.14 either way. ### The census idiom ```python import gc from collections import Counter def census(): gc.collect() return Counter(type(obj).__name__ for obj in gc.get_objects()) before = census() run_one_batch() after = census() print((after - before).most_common(15)) ``` Three details make this useful rather than noise: - **`gc.collect()` first.** Without it the snapshot includes cyclic garbage that is dead but not yet reclaimed, and every diff is polluted by collection timing rather than by your workload. - **Diff, never absolutes.** An idle interpreter already carries thousands of functions, dicts and wrapper descriptors. Only the delta across a workload means anything. - **Repeat the workload.** Run the batch several times and check the delta scales with iterations. A one-off delta is usually warm-up: interned constants, lazily imported modules, a filled cache that has now reached its ceiling. Using `type(obj).__name__` keeps the counter keys hashable and printable; using `type(obj)` itself works too and disambiguates same-named classes from different modules, at the cost of holding a reference to each class. ### What the census cannot see This is the part interviewers probe, because getting it wrong sends people down a blind alley. The collector only tracks objects that can refer to other objects. Atomic values do not: `int`, `float`, `str`, `bytes` and `bool` instances are never tracked, and CPython also untracks tuples and dicts once it can prove they contain only untracked items. `gc.is_tracked()` will confirm this on any object. The practical consequence is that a leak made of strings shows in the census as growing `list` or `dict` counts, not as growing `str` counts -- so you learn the shape of the container rather than the payload, and you size the payload some other way. Memory held outside the Python heap is invisible too: buffers allocated by a native extension, memory the allocator has freed to its own pools but not returned to the OS, and fragmentation all move RSS without moving any count in the census. That is why the census is a triage step and not a memory accounting tool -- it tells you which *kind* of Python object is multiplying, and nothing about bytes. ### Cost and safety in production The call walks the whole tracked heap and materialises a list as long as it. On a large process that is tens of millions of pointers: hundreds of milliseconds, plus a transient allocation, plus a reference to every tracked object that keeps anything otherwise dying alive until the list is released. Assign it, use it, then `del` it -- and never hold a census list across a request or stash it in a global, or the diagnostic becomes the leak. Because it stops nothing and takes no lock of its own, it is safe to run in a live process from a debug endpoint or a signal handler, but treat it as an occasional operation rather than a periodic metric. In a multi-threaded process the snapshot is inherently fuzzy: other threads keep allocating while you iterate. ### Where it sits in a leak hunt A disciplined sequence is: confirm growth is real and monotonic, take a type census diff to learn what is accumulating, then take one instance of the accumulating type and walk backwards to find the object still referring to it. The census is deliberately cheap in thinking effort -- it needs no instrumentation, no restart, and no prior hypothesis, which is exactly why it goes first. Line-level attribution of allocations is a different tool with a different setup cost, and it becomes far more useful once the census has told you which type to care about.