list() uses slightly more memory than list comprehension
I think you're seeing over-allocation patterns this is a sample from the source:
/* This over-allocates proportional to the list size, making room
* for additional growth. The over-allocation is mild, but is
* enough to give linear-time amortized behavior over a long
* sequence of appends() in the presence of a poorly-performing
* system realloc().
* The growth pattern is: 0, 4, 8, 16, 25, 35, 46, 58, 72, 88, ...
*/
new_allocated = (newsize >> 3) + (newsize < 9 ? 3 : 6);
Printing the sizes of list comprehensions of lengths 0-88 you can see the pattern matches:
# create comprehensions for sizes 0-88
comprehensions = [sys.getsizeof([1 for _ in range(l)]) for l in range(90)]
# only take those that resulted in growth compared to previous length
steps = zip(comprehensions, comprehensions[1:])
growths = [x for x in list(enumerate(steps)) if x[1][0] != x[1][1]]
# print the results:
for growth in growths:
print(growth)
Results (format is (list length, (old total size, new total size))):
(0, (64, 96))
(4, (96, 128))
(8, (128, 192))
(16, (192, 264))
(25, (264, 344))
(35, (344, 432))
(46, (432, 528))
(58, (528, 640))
(72, (640, 768))
(88, (768, 912))
The over-allocation is done for performance reasons allowing lists to grow without allocating more memory with every growth (better amortized performance).
A probable reason for the difference with using list comprehension, is that list comprehension can not deterministically calculate the size of the generated list, but list() can. This means comprehensions will continuously grow the list as it fills it using over-allocation until finally filling it.
It is possible that is will not grow the over-allocation buffer with unused allocated nodes once its done (in fact, in most cases it wont, that would defeat the over-allocation purpose).
list(), however, can add some buffer no matter the list size since it knows the final list size in advance.
Another backing evidence, also from the source, is that we see list comprehensions invoking LIST_APPEND, which indicates usage of list.resize, which in turn indicates consuming the pre-allocation buffer without knowing how much of it will be filled. This is consistent with the behavior you're seeing.
To conclude, list() will pre-allocate more nodes as a function of the list size
>>> sys.getsizeof(list([1,2,3]))
60
>>> sys.getsizeof(list([1,2,3,4]))
64
List comprehension does not know the list size so it uses append operations as it grows, depleting the pre-allocation buffer:
# one item before filling pre-allocation buffer completely
>>> sys.getsizeof([i for i in [1,2,3]])
52
# fills pre-allocation buffer completely
# note that size did not change, we still have buffered unused nodes
>>> sys.getsizeof([i for i in [1,2,3,4]])
52
# grows pre-allocation buffer
>>> sys.getsizeof([i for i in [1,2,3,4,5]])
68
Thanks everyone for helping me to understand that awesome Python.
I don't want to make question that massive(that why i'm posting answer), just want to show and share my thoughts.
As @ReutSharabani noted correctly: "list() deterministically determines list size". You can see it from that graph.
When you append or using list comprehension you always have some sort of boundaries that extends when you reach some point. And with list() you have almost the same boundaries, but they are floating.
UPDATE
So thanks to @ReutSharabani, @tavo, @SvenFestersen
To sum up: list() preallocates memory depend on list size, list comprehension cannot do that(it requests more memory when it needed, like .append()). That's why list() store more memory.
One more graph, that show list() preallocate memory. So green line shows list(range(830)) appending element by element and for a while memory not changing.
UPDATE 2
As @Barmar noted in comments below, list() must me faster than list comprehension, so i ran timeit() with number=1000 for length of list from 4**0 to 4**10 and the results are
