Memory Optimization

Key features

• sys.getsizeof(obj) reports real bytes, including overhead — good for spotting one large object
• An object is freed only once nothing references it — a lingering reference is a common growth cause
• a = b never copies — both names reference the same object, so mutating either affects both
• gc.get_referrers(obj) answers "what is still holding this object" during an investigation
• A steadily growing sys.getsizeof() on one container signals an unbounded cache or leak

Command

import sys
sys.getsizeof(obj)          # real size, including overhead

import gc
gc.get_referrers(obj)       # what is still referencing obj -- for investigating a leak

Key features

• list.append() occasionally triggers a resize that over-allocates room for future appends
• sys.getsizeof(a_list) reports the CONTAINER's size only — not the objects it references
• A list of 1,000,000 ints costs more than that count suggests — one pointer per item too
• tuple is slightly more memory-efficient than list for fixed data — it never over-allocates
• A dict/set also over-allocates its hash table, for the same amortized-growth reason

Command

import sys

lst = []
for i in range(1000):
    lst.append(i)
    # sys.getsizeof(lst) grows in jumps, not one byte at a time

Key features

• A generator expression is constant-size, regardless of how many items it will produce
• A list comprehension allocates space for every item immediately, all at once
• Any function using yield is a generator function — calling it returns a generator, unrun
• sum(), any(), all() only need one item at a time — a generator argument is enough
• A generator can only be consumed once — there is no rewinding it, unlike a list

Command

[x for x in range(1_000_000)]    # a real list -- all items exist now
(x for x in range(1_000_000))    # a generator -- constant-size, lazy

Key features

• A regular instance carries a __dict__ (hundreds of bytes) even for one or two attributes
• A __slots__ instance has no __dict__ — its attributes live in fixed-size slots instead
• The saving PER INSTANCE is modest; the saving across many thousands of instances is not
• __slots__ is most worth adding to classes instantiated in bulk — rows, events, graph nodes
• It is rarely worth adding to a class with a handful of long-lived instances — savings never accumulate

Command

class Row:
    __slots__ = ("id", "value")
    def __init__(self, id, value):
        self.id = id
        self.value = value

# worth adding when Row is instantiated in bulk (many thousands+)

Key features

• copy.copy(x) creates a new outer object; nested mutable objects are still shared, not duplicated
• copy.deepcopy(x) recursively duplicates every nested object — genuinely more memory used
• A deep copy of a large nested structure can cost as much memory as the original, doubling usage
• Reach for deepcopy only when independence is actually required — a shallow copy is cheaper otherwise
• A flat structure (no nested mutables) makes shallow and deep copy cost the same — nothing to duplicate

Command

import copy
shallow = copy.copy(original)      # cheap -- nested objects shared
deep = copy.deepcopy(original)     # costs real memory -- nested objects duplicated

Key features

• The most common real leak: an unbounded, module-level cache or list that only ever grows
• A registered callback or subscriber never unregistered keeps its target alive indefinitely
• Steadily growing process RSS, with no drop, is the symptom that starts an investigation
• tracemalloc.take_snapshot(), compared across two points, shows which allocations grew
• The fix is almost always an eviction policy, a max size, or an explicit unsubscribe step

Command

import tracemalloc

tracemalloc.start()
snapshot1 = tracemalloc.take_snapshot()
# ... run the suspected-leaking code ...
snapshot2 = tracemalloc.take_snapshot()

top_stats = snapshot2.compare_to(snapshot1, "lineno")
for stat in top_stats[:5]:
    print(stat)

Key features

• gc.collect() forces a collection now, returns how many objects it freed — a useful signal
• gc.garbage lists objects the collector found uncollectable (rare, a __del__ complication)
• A steady rise in gc.get_count() alongside growing memory suggests cycles outpacing collection
• Breaking a cycle deliberately (a weak reference on one side) avoids relying on the collector
• Most programs never think about this — it matters only once investigation points here

Command

import gc

freed = gc.collect()   # force a collection, see how many objects it found
print(f"freed {freed} unreachable objects")
print("uncollectable:", gc.garbage)

Key features

• A plain dict used as a cache holds strong references — cached values stay alive as long as the cache does
• weakref.WeakValueDictionary holds weak references — an entry vanishes once nothing else references it
• The standard fix for a cache that should reflect what is CURRENTLY in use, not keep everything alive
• Not every object supports weak references — plain int, str, tuple do not by default
• A bare weakref.ref(obj) needs manually checking whether the object is still alive (ref() returns None once freed)

Command

import weakref

cache = weakref.WeakValueDictionary()
cache["key"] = some_object   # a WEAK reference -- does not keep some_object alive
# once nothing else references some_object, it is freed AND removed from cache

Key features

• @lru_cache(maxsize=None) caches EVERY distinct argument set forever
• Called with highly varied arguments (a user ID), an unbounded cache grows without limit
• @lru_cache(maxsize=1000) bounds it — least-recently-used entries are evicted once full
• A cache keyed on something high-cardinality (a request ID) is a common unbounded pattern
• The fix is almost always a maxsize, a TTL, or switching to a weakref-based cache

Command

from functools import lru_cache

@lru_cache(maxsize=1000)   # bounded -- evicts least-recently-used once full
def compute(x):
    ...

Key features

• A single tracemalloc snapshot shows a moment; comparing TWO shows what grew between them
• snapshot.statistics("lineno") groups allocations by source line — fast way to find a culprit
• tracemalloc.get_object_traceback(obj) shows exactly where a specific object was allocated
• gc.get_objects(), filtered by type, counts live instances of a suspected class
• Take snapshots at two points separated by real traffic/time, not immediately back to back

Command

import gc

# count live instances of a suspected class
suspects = [obj for obj in gc.get_objects() if isinstance(obj, SuspectedClass)]
print(f"{len(suspects)} live instances")