Why a Tiny List Still Costs More Than Its Raw Data

Question

A 2-element long vector only holds 16 bytes of actual data (2×8). Why does it use noticeably more memory than that, and how would you measure exactly how much an expression allocates?

Solution

\ts l:2 3

\ts reports both the time an expression took and the bytes it allocated — useful for seeing the real cost of an expression, not just its theoretical one.

Explanation

Every list carries a small, fixed amount of metadata alongside its raw elements — covering things like its type, its element count, its reference count, and any attribute applied to it. That overhead applies before the buddy allocator even gets involved: the requested size is "raw data + metadata," and only then does the allocator round that total up to the next power-of-two block.

For a tiny list like this one, the fixed overhead is often bigger, relatively speaking, than the data itself — so even a 2-element vector ends up needing meaningfully more than 2×8 bytes once metadata is added in, before any block-size rounding on top of that. This is why very small objects are disproportionately expensive per element compared to large ones: the fixed overhead is paid once regardless of size, so it matters far less once a vector is large enough to dominate its own footprint.