Why does a Python instance with three attributes cost far more memory than three raw values?

### Nothing in Python is a raw value At the C level every Python object begins with a fixed header. On a 64-bit build that header is two machine words, 16 bytes: a reference count and a pointer to the object's type. `sys.getsizeof(object())` returns exactly that 16. Everything else an object needs — its attribute storage, its variable-length payload, the bookkeeping the cycle collector wants — is laid out after those two words. That header is charged **per object**, and Python creates far more objects than a systems-language programmer expects. A `float` attribute is not eight bytes of IEEE-754 sitting in the instance; it is a separate heap object of 24 bytes (header plus the double) that the instance merely points at. A small `int` is 28 bytes. So "three numbers" is really one instance plus up to three other objects plus three pointers. ### Where a plain instance keeps its attributes For a class that does not declare `__slots__`, each instance gets its own attribute storage. Historically that meant a full private dictionary per instance, which is why the folklore figures for instance overhead are so large. Two changes shrank it: * **3.3 (PEP 412) key-sharing dictionaries** — instances of the same class share one copy of the key table, so each instance stores only the values. * **3.11 inline values** — CPython stores those values in a compact array laid out with the object itself and only materializes a real dictionary object when something actually asks for `obj.__dict__` (or `vars(obj)`, or sets an attribute in a way that forces it). The consequence for interviews: a plain instance on 3.14 is *much* cheaper than a 2015 blog post claims, but it is still nowhere near "the size of its data". Measured on 3.14, a two-attribute class costs about 96 bytes per instance including the list slot that holds it; the same class with `__slots__` costs about 56. ### The container adds its own tax Objects almost never live alone. A `list` holding a million floats stores a million *pointers* — eight bytes each, in one contiguous array — and each pointed-at float is its own 24-byte object. That is roughly 32 bytes of memory for eight bytes of information, a 4x tax before you count the list's own header and its over-allocation slack. A `dict` is worse per entry, because it stores a hash, a key pointer and a value pointer. ### Why `sys.getsizeof` will not show you this `sys.getsizeof` is shallow. It asks the object's own `__sizeof__` and adds the garbage-collector bookkeeping, and it stops there: it never follows a pointer. `sys.getsizeof` on the instance above reports 48 while the instance genuinely costs about twice that once you count the values array and the objects it points at. To see the real figure you either walk the object graph yourself (deduping by `id`, since two attributes can point at one object) or you allocate a large number of instances under `tracemalloc` and divide. ### What follows from all this Three practical consequences, and interviewers are usually after at least one of them. 1. **Small objects in bulk are the expensive shape.** A million rows modelled as a million tiny instances costs the headers a million times. The same data in a handful of typed buffers, or in columns, costs the header a handful of times. 2. **Per-object cost is what `__slots__` attacks.** Declaring the attribute names up front lets the class store them at fixed offsets in the instance and drops the per-instance dictionary machinery entirely. 3. **Measure on the build you deploy.** The free-threaded build, officially supported from 3.14 (PEP 779), carries extra per-object fields so that reference counting can be thread-safe; object sizes there are not the ones you measured on the default build. ### The answer that sounds senior "Every object pays a two-word header, and Python boxes numbers, so an instance is a header plus attribute storage plus a pointer per attribute plus a separate boxed object per value. On 3.14 the attribute values live inline in the object until something asks for `__dict__`, so the per-instance figure is smaller than it used to be — but the multiplier is still per-object, which is why the cost only ever bites at scale."