Memory and objects: why an int costs 28 bytes and where the leak actually lives

Why Python objects are fat

Before you can find a memory leak, you need to understand what you are paying for. When you know the header cost for each type, the RSS numbers stop being mysterious and start being arithmetic.

Every Python object begins with a 16-byte header on 64-bit builds: an 8-byte reference count and an 8-byte pointer to its type. Payload comes after. The everyday numbers:

import sys
sys.getsizeof(1)       # 28  — header + size + one 30-bit digit
sys.getsizeof(1.0)     # 24  — header + one C double
sys.getsizeof("a")     # 50  — header + flags + len + ASCII buffer
sys.getsizeof({})      # 64  — empty dict, grows in power-of-2 jumps
sys.getsizeof([])      # 56  — empty list

This is the per-object price of dynamism: every value heap-allocated, typed at runtime, reference-counted on every binding. A C double is 8 bytes in a register; a Python float is 24 bytes on the heap plus the 8-byte pointer something holds to reach it. Multiply by ten million and the dynamism bill arrives as gigabytes.

getsizeof lies shallowly

sys.getsizeof reports one object’s own allocation — for containers, that means the pointer table, not the contents. A list of one million floats: getsizeof(lst) says about 8 MB (a million 8-byte slots plus header), while the real footprint is that 8 MB plus 24 MB of float objects — 32 MB minimum, more once allocator fragmentation gets a vote. Honest sizing is recursive: walk gc.get_referents with a seen-set, or use a heap profiler instead of arithmetic.

Refcounting, and when the cycle collector earns its keep

CPython frees an object the instant its refcount hits zero — deterministic, immediate, the reason file handles close promptly in well-written code. What refcounting cannot free is a cycle: parent and child holding references to each other never reach zero. That is the cycle GC’s job: three generations, threshold-triggered (by net allocations), survivors promoted upward. Cycles build up in object graphs with back-references — trees whose nodes point at their parent, ORM rows pointing at their session, and the classic sleeper: a stored exception keeps its traceback, the traceback keeps every frame, and each frame keeps all its locals alive.

gc.collect() is a diagnostic as much as a remedy: if you force a full collection and memory barely moves — the Hook’s two megabytes — your growth is reachable, and no garbage collector will ever save you. The leak is a data structure doing exactly what it was told.

slots revisited: the lever for object count

The data-model unit established the mechanism; here is the capacity math. A five-field plain instance costs roughly 250+ bytes once its __dict__ exists; the slotted version about 104. At 1 M objects that is ~250 MB versus ~104 MB — and at 40 M it is the difference between a pod that fits and one that OOMs. @dataclass(slots=True) makes it one flag. Slots are the right lever when object count is the problem and the field set is fixed.

Lists of objects vs array vs numpy: the order-of-magnitude table

When the data is numeric and high-cardinality, the win is to stop having objects at all:

A contiguous typed buffer is 4-10x smaller and cache-friendly; the pointer-chasing list is both fat and slow to traverse. This table is also the bridge to the next lesson — numpy is a C extension someone already wrote.

tracemalloc: finding the allocation site, not the symptom

RSS tells you that memory grew; tracemalloc tells you which line allocated it. Start it early (the frame depth costs memory and CPU, so enable it for the hunt, not forever), snapshot twice, diff:

import tracemalloc
tracemalloc.start(25)            # keep 25 frames per allocation site

s1 = tracemalloc.take_snapshot()
# ... 30 minutes of representative traffic ...
s2 = tracemalloc.take_snapshot()

for stat in s2.compare_to(s1, "lineno")[:10]:
    print(stat)                  # growth ranked by allocating line

py-spy cannot do this — it samples CPU stacks, not allocations. For native + Python allocation tracking, memray is the heavier third-party option; tracemalloc is the stdlib tool that ships everywhere.

Leak patterns that are not leaks

The recurring villains are all reachable growth: module-level caches and registries that only ever append; lru_cache(maxsize=None) keyed by high-cardinality arguments; closures and stored exceptions pinning frames (and every local in them); append-only lists on long-lived singletons. True C-level leaks exist but are rare in pure Python. When RSS grows, the first question is not “what leaked” but “which data structure is doing its job too well”.