11.10 Performance

flowchart TD A["Memory (3 items)"] --> A1["tuple: 64 bytes"] A --> A2["list: 88 bytes"] B["Literal creation speed"] --> B1["tuple: faster"] B --> B2["list: slower"] C["Why"] --> C1["tuple: no over-allocation needed"] C --> C2["list: reserves extra capacity for append()"]

Tuples skip the extra bookkeeping lists need to support mutation — the right choice for fixed, read-only data.

Memory Usage

>>> import sys
>>> sys.getsizeof((1, 2, 3))
64
>>> sys.getsizeof([1, 2, 3])
88

Tuple vs List

Property	`tuple`	`list`
Mutable?	No	Yes
Memory (3 items)	64 bytes	88 bytes
Hashable?	Yes (if contents are)	Never
Has spare capacity?	No	Yes
Methods available	2 (`count`, `index`)	11 (see 10.7 List Methods)

Speed Comparison

Creating a tuple literal is measurably faster than creating an equivalent list literal, since there’s no spare-capacity bookkeeping to set up:

>>> import timeit
>>> timeit.timeit(lambda: (1, 2, 3, 4, 5), number=1000000)
0.0246     # seconds -- illustrative, will vary by machine
>>> timeit.timeit(lambda: [1, 2, 3, 4, 5], number=1000000)
0.0623

Quick Interview Answer

“Tuples are both smaller and faster than an equivalent list, and both differences trace back to the same root cause: a list has to reserve spare capacity and manage the possibility of growing, while a tuple’s size is fixed forever at creation, so CPython allocates exactly what’s needed and skips all of that bookkeeping. The trade-off is real, though — a tuple gives up 9 of the 11 list methods (only count() and index() remain) in exchange for that speed and the hashability that comes with immutability. For genuinely fixed data, that trade is a clear win; for anything that grows or shrinks, it isn’t a choice at all — a list is required.”

Common Mistakes

Treating the tuple/list performance gap as large enough to matter for ordinary application code — it’s real but small; the decision between them should be driven by mutability and hashability needs, not micro-benchmarks.
Converting a list to a tuple purely for a speed boost in a hot loop where the collection still needs to grow or shrink — that requirement rules out a tuple regardless of performance.
Forgetting the memory difference scales with collection size — the gap in a small tuple/list pair is a few dozen bytes, but the same relative saving matters more when creating millions of small fixed records.