Python Memory Management

What Python Memory Management Means

Python memory management is not one mechanism. It is a stack of decisions: where an object lives, how long it stays alive, whether its storage can be reused, and whether the operating system sees that memory return immediately.

The most useful mental model is this: Python code works with objects through references. CPython, the standard Python implementation, manages those objects inside the process. The operating system still manages virtual memory and physical pages underneath CPython, but Python programmers usually feel the object layer first.

Think of a Python process like a workbench. Names in your code are labels stuck to parts on the bench. The object is the actual part. CPython tracks how many labels and containers still point at the part, and it keeps bins of reusable storage for small parts that appear often.

Names Point to Objects

A variable is not a box that contains a value. It is a name bound to an object. Assignment creates another reference to the same object unless your code explicitly creates a copy.

a = []
b = a

b.append("item")
print(a)  # ["item"]

Both a and b point to the same list. The append changed the object, not one private copy owned by b.

This is why Python memory questions often start with reachability: can any live name, stack frame, object, cache, closure, or container still reach the object? If yes, the object is still alive.

What a Python Object Contains

Every CPython object carries metadata before the visible payload. At minimum, CPython needs to know the object's reference count and its type.

Python object
├── reference count
├── type pointer
└── type-specific payload

That metadata is powerful: it lets CPython dispatch operations dynamically and free most objects as soon as their reference count reaches zero. It also means a small visible value can cost more memory than the value alone suggests.

For example, a list is not just its elements. It also has a list object header, length, capacity, and a pointer array that points to element objects. A list of integers therefore stores references to integer objects, not raw machine integers packed into one contiguous numeric buffer.

Use compact containers when the layout matters:

from array import array

# Flexible, but each element is a Python int object.
values = [1, 2, 3, 4]

# Compact C-style integers.
packed = array("I", [1, 2, 3, 4])

The Allocation Path

When CPython needs storage for an object, it does not always call the operating system directly. The path depends on the object type and allocation size.

1. Type-specific allocators may reuse object shells for common types.
2. Many small requests up to 512 bytes go through PyMalloc.
3. Larger requests go to the platform allocator, such as malloc.
4. The operating system provides virtual memory pages below those allocators.

This layered design exists because Python programs create and destroy many small objects. Calling the system allocator for every tiny tuple, frame, dict entry, or short-lived object would be expensive and would fragment memory more quickly.

PyMalloc: Arenas, Pools, and Blocks

PyMalloc is CPython's small-object allocator. Its job is to serve common small allocation requests quickly.

arena: 256 KiB chunk from the system allocator
└── pool: 4 KiB region for one size class
    └── block: one allocation of that size class

A pool serves one block size. For example, one pool may serve 32-byte blocks, another may serve 64-byte blocks, and another may serve 256-byte blocks. When a small object is freed, CPython can often put that block back into the right pool for reuse.

This explains a common surprise: deleting a large number of Python objects does not guarantee that your process RSS immediately drops. CPython may keep arenas and pools around because it expects future allocations. The memory is available to the Python process, even if the operating system has not reclaimed it.

Object Lifetime: Reference Counting First

CPython primarily uses reference counting. Each object tracks how many live references point to it. When that count reaches zero, CPython can immediately destroy the object.

a = []
b = a
box = [a, a]

del b
box = None
del a

sys.getrefcount can demonstrate the idea, but do not treat the exact printed number as universal. The function receives the object as an argument, so it includes a temporary reference created by the call itself. Builds, debuggers, interactive shells, and surrounding code can also affect the count.

import sys

items = []
print(sys.getrefcount(items))

Reference counting alone cannot reclaim every structure. If two objects point to each other and nothing else points to them, their reference counts may stay above zero. CPython's cyclic garbage collector exists to find and clean up those unreachable cycles.

Reuse: Caches, Interning, and Free Lists

CPython also uses reuse paths to avoid repeated allocation work.

Small integers: CPython pre-creates a range of small integer objects, so common values can be reused.

a = 100
b = 100
print(a == b)  # True: same value

String interning: Some strings may be interned so identical strings can share one object, especially identifiers and strings explicitly passed through sys.intern.

import sys

left = sys.intern("code")
right = sys.intern("code")
print(left is right)

Free lists and object caches: CPython may keep recently freed object shells for types such as tuples, lists, frames, and floats. Reusing a shell can be faster than asking the allocator for fresh storage.

Treat these as implementation details, not application logic. Use == for value equality. Use is for identity checks such as x is None, or when you explicitly need to know whether two names point to the exact same object.

Measuring Memory Before Optimizing

Memory optimization starts with measurement because the visible Python code is often not where memory is retained.

Use sys.getsizeof to inspect the shallow size of one object:

import sys

items = [1, 2, 3]
print(sys.getsizeof(items))  # list shell only

Use tracemalloc to compare allocation snapshots:

import tracemalloc

tracemalloc.start()

data = [str(i) for i in range(100_000)]

snapshot = tracemalloc.take_snapshot()
for stat in snapshot.statistics("lineno")[:5]:
    print(stat)

Use process-level tools when you care about RSS, container limits, or whether memory returned to the operating system:

python -m memory_profiler script.py
ps -o pid,rss,command -p <pid>

These tools answer different questions. sys.getsizeof answers "how large is this object shell?" tracemalloc answers "where did Python allocate memory?" RSS answers "how much memory does the operating system think this process is holding?"

Practical Fixes

Many tiny class instances usually means each instance is carrying object metadata plus a __dict__. Measure first, then consider @dataclass(slots=True), __slots__, tuples, arrays, or NumPy.

Peak memory spikes often come from materializing an entire list, slice, or copy. Stream with generators, process chunks, or remove intermediate containers.

Process memory grows forever usually means objects are still reachable through caches, globals, closures, queues, or long-lived task state. Compare tracemalloc snapshots and bound caches with lru_cache(maxsize=...).

Deleting objects does not reduce RSS can be normal when CPython or the platform allocator keeps memory for reuse. Check whether Python can reuse the memory before assuming a leak.

Slow code creates many temporaries when repeated concatenation or copying builds short-lived objects. Use join, careful comprehensions, preallocation, or streaming.

Slots for Many Similar Objects

__slots__ removes the per-instance dictionary when each instance has a fixed set of attributes.

from dataclasses import dataclass

@dataclass(slots=True)
class Point:
    x: float
    y: float

Slots are useful when you create many instances and have measured instance overhead as the problem. They are not a universal default: dynamic attributes, some inheritance patterns, and debugging workflows can become less convenient.

Generators for Streaming Data

Generators avoid holding an entire result in memory.

def squares(items):
    for item in items:
        yield item * item

for value in squares(range(1_000_000)):
    consume(value)

This is most useful when the consumer can process values one at a time. If a later step converts the generator back into a list, the peak-memory benefit may disappear.

Bounded Caches

Unbounded caches are a common source of retained memory.

from functools import lru_cache

@lru_cache(maxsize=256)
def parse_schema(schema_id):
    return load_and_parse_schema(schema_id)

The important part is not the decorator itself. The important part is the bound: the program has an explicit upper limit on how many results it will retain.

Common Misconceptions

"del frees memory back to the OS." del removes a reference. If the object becomes unreachable, CPython can destroy it. The allocator may still keep the underlying memory for reuse inside the process.

"Reference counting means Python has no garbage collector." CPython uses reference counting for immediate cleanup and a cyclic garbage collector for unreachable cycles.

"is tells me whether two values are equal." is tests identity. Some objects are cached or interned, so identity can surprise you. Use == for value equality.

"A list of integers is just a compact array of machine ints." A Python list stores references to Python objects. Use array, NumPy, or another compact container when dense numeric storage is the goal.

Related Concepts

• Python Garbage Collection: How CPython finds unreachable reference cycles.
• Python Object Model: Why types, attributes, and methods behave the way they do.
• How RAM Works: The hardware memory layer beneath Python's process.
• CPU Cache Lines: Why memory layout affects performance.

Further Reading

• Python memory management documentation
• tracemalloc documentation
• gc module documentation