performance of tuple-less Python?

[Tim Peters]

[Greg Wilson]
> Has anyone ever built a version of Python that didn't include tuples,
> and looked at the performance of code that consistently used lists
> instead?  I'm curious as to whether the use of tuples (which I believe
> are conceptually redundant)

They do differ semantically, due to immutability (see other msgs).

> actually has a significant positive impact on the interpreter's
> performance on non-trivial codes (i.e. once caching, instruction
> ordering, and all other effects have come into play).

tuple[i] and list[i] access have (up to accidents of architecture) identical
cost; tuple[i] may be faster in pathological cases because of cache effects
(a tuple's object header is contiguous with the tuple's content vector; a
list's object header is not generally contiguous with the list's content
vector).

A predictably bigger effect is that allocating a list object requires two
malloc() calls (one for the object header, another for the content vector).
Allocating a tuple object typically requires no malloc calls (because tuples
are expected to be short, Python maintains internal free lists of tuples of
various small sizes, and recycles them directly from there).  Similarly,
destroying a list requires two free() calls, while destroying a tuple
typically just links it onto the appropriate internal free list.

So creation and destruction of tuples goes faster, and tuples are more
memory-efficient.  Indeed, I've had larger programs that wouldn't run at all
on a 32Mb machine (constant disk thrashing) before I changed lists to
tuples!

That doesn't mean all possible implementations would have these
characteristics; they're the truth for the implementation that exists,
though.

if-tuples-didn't-exist-someone-would-invent-them-ly y'rs  - tim