array.array vs list[int] vs bytes Lab

Intro — what this post promises

Storing millions of integers: list[int], array.array('i'), or a packed bytearray / memoryview? Folklore says arrays are “more compact and faster.” This lab measures bytes per element and sum / iterate / index ops/s on Linux localhost.

Related links:

• deque vs list queue localhost lab
• itertools vs python loops localhost lab
• dataclass vs slots vs dict localhost lab
• struct pack vs to_bytes localhost lab
• copy vs deepcopy localhost lab
• lru_cache hit vs miss localhost lab
• set vs list membership localhost lab
• json vs orjson vs msgpack localhost lab

Lab honesty (1 Oct 2026 IST): Python 3.13.5. N=2,000,000. Affiliates: 0. Density uses itemsize / estimated sys.getsizeof — not a full heap profiler. sum(list) is a C-accelerated special case.

Verdict up front: density wins for array('i') — 4 B/elem vs list ~36 B/elem (~9×). Throughput is the twist: sum(list) ~196M/s beats sum(array) ~102M because each C int becomes a Python int. Manual bytearray unpack is ~5.8M/s.

Structures

Lab topology

N = 2_000_000
Throughput: sum(), for-x-in, stride-7 index
Metric: p50 ops/s (elements or probes)
Density: array.itemsize / sizeof estimate

Script: lab-evidence/56-array-vs-list-ints/results/run_lab.py.

Memory density

sys.getsizeof on the list object alone is tiny; the ~36 B figure includes a sample of int object sizes × N. That is the RAM story for large numeric vectors.

Lead table — throughput (p50)

Reading it

• RAM: array('i') / packed bytes are ~9× denser than a list of small ints. That alone can decide caching and GC pressure.
• sum(list) is not a fair “list is faster” lesson — CPython’s sum on lists of ints is specialized. Fairer: the for x in …: s += x arms, where list is still ahead (~1.41×) because array iteration boxes.
• Index stride is nearly tied — boxing happens either way when you pull a Python int out.
• Hand-unpacking bytearray is for I/O buffers, not inner-loop math.

For numeric crunching that stays in C (NumPy), you leave Python’s boxing tax entirely. This lab is stdlib only.

Pitfalls

1. Choosing array for speed of sum() — memory was the win; sum(list) can win.
2. array('l') / platform sizes — 'i' is 4 bytes here; check itemsize.
3. Assuming memoryview is free — iteration still produces Python ints.
4. RSS peak noise — prefer buffer nbytes for density claims.

When to pick what

Reproduce

python3 lab-evidence/56-array-vs-list-ints/results/run_lab.py

Evidence: /workspace/lab-evidence/56-array-vs-list-ints/results/.

Closing

Compact ≠ always faster in pure Python. On this box array('i') is 4 B/elem vs list ~36 B, but sum(list) hits ~196M/s vs array ~102M. Use arrays for memory; don’t expect them to beat list iteration without staying in C.