By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
444,050 Members | 1,019 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 444,050 IT Pros & Developers. It's quick & easy.

Technical question on complexity.

P: n/a
Anybody knows where I can find a concrete and guaranteed answer to the following
extremely basic and simple question?

What is the complexity of appending an element at the end of a list?
Concatenating with another?

The point is that I don't know what is the allocation policy... If Python lists
are standard pointer-chained small chunks, then obviously linear. But perhaps
there is some optimisation, after all a tuple uses a contiguous chunk, so it
*might* be possible that a list is essentially equivalent to an array, with its
length stored within, and adding something may be done in constant time (unless
the whole stuff is copied, which again makes the complexity related to the size
of existing structure...)

It is probably possible to retrieve this information from the sources, but I try
first an easier way.
Thank you.

Jerzy Karczmarczuk
Oct 13 '05 #1
Share this Question
Share on Google+
1 Reply


P: n/a
Jerzy Karczmarczuk wrote:
Anybody knows where I can find a concrete and guaranteed answer to the following
extremely basic and simple question?

What is the complexity of appending an element at the end of a list?
amortized O(1)
Concatenating with another?
O(n)
The point is that I don't know what is the allocation policy... If Python lists
are standard pointer-chained small chunks, then obviously linear. But perhaps
there is some optimisation, after all a tuple uses a contiguous chunk, so it
*might* be possible that a list is essentially equivalent to an array, with its
length stored within, and adding something may be done in constant time


a list consists of a single array of PyObject pointers, plus "allocated" and
"current size" fields. when you append, allocation is only done when needed,
and the new size is chosen carefully to keep the number of allocations low.
see the source for details (the exact "overallocation" strategy varies some-
what in different Python versions).

</F>

Oct 13 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.