Lists vs Arrays: Performance Questions

The reason a list is slower than a typed array comes down to what a list slot holds. A list is an array of pointers to objects, so every integer in it is a separate object with its own memory and its own reference count. A typed array stores the raw values inline, with no per-element object and no reference counting.

That makes array.array the better choice when you have a large number of numbers of the same type. The memory saving is roughly four to eight times for 64-bit values, the cache behaviour is better because the data is contiguous, and there is no per-element object overhead at all.

The catch is that array.array is type-restricted. Its itemsize and typecode are fixed at creation, so you cannot mix an int and a string in one array, and assigning the wrong type raises a TypeError. It also lacks the convenience methods a list has — no append of arbitrary types, and slicing gives you a new array rather than a list.

NumPy goes further and is what you would normally reach for in numerical work. It is not just typed, it is vectorised: operations apply across the whole array without Python-level loops, which is usually a far bigger win than the memory saving. A NumPy array of a million floats uses about eight megabytes and multiplies in milliseconds.

The practical rule for an interview: a list for general-purpose collections of mixed objects, array.array for a large homogeneous sequence of simple values where you want to save memory, and NumPy for anything involving real numerical computation.

The difference is visible directly with the sys module.

import array
import sys

values = list(range(100_000))
packed = array.array("i", range(100_000))

print(sys.getsizeof(values))    # 800056
print(sys.getsizeof(packed))    # 408360
print(values[0], packed[0])    # 0 0
print(type(packed).__name__)   # array

The list occupies 800,056 bytes and the array 408,360 bytes, so the array uses roughly half the space. That ratio is the headline, but the reported figures understate the real difference, because getsizeof on a list counts only the array of pointers — the 100,000 integer objects it points at are allocated separately and are not included. The array stores the values inline as four-byte signed integers, so its 408,360 bytes is the entire cost.

The typecode matters. The i code is a signed integer, and its size depends on the platform — four bytes on most modern machines. The l and q codes give long and long long, and f and d give single and double precision floats. You can check the size with array.array("i").itemsize.

Two practical notes. Because the array stores raw values, reading an element gives back a freshly created Python int rather than the original object, which is why the same integer appearing twice in a list is the same object while in an array it is not. And the array is limited to one type, so you cannot mix an int and a string in it.