list () використовує трохи більше пам'яті, ніж розуміння списку

Question 1

Тож я грав з listпредметами і виявив трохи дивної речі, яка, якщо listстворена з list()нею, використовує більше пам'яті, ніж розуміння списку? Я використовую Python 3.5.2

In [1]: import sys
In [2]: a = list(range(100))
In [3]: sys.getsizeof(a)
Out[3]: 1008
In [4]: b = [i for i in range(100)]
In [5]: sys.getsizeof(b)
Out[5]: 912
In [6]: type(a) == type(b)
Out[6]: True
In [7]: a == b
Out[7]: True
In [8]: sys.getsizeof(list(b))
Out[8]: 1008

З документів :

Списки можуть бути побудовані кількома способами:

Використання пари квадратних дужок для позначення порожнього списку: []

Використовуючи квадратні дужки, розділяючи елементи комами: [a],[a, b, c]

Використання розуміння списку: [x for x in iterable]

Використання конструктора типу: list()абоlist(iterable)

Але, здається, при list()його використанні використовується більше пам'яті.

І listчим більше, тим більше розрив.

Чому так трапляється?

ОНОВЛЕННЯ №1

Тест з Python 3.6.0b2:

Python 3.6.0b2 (default, Oct 11 2016, 11:52:53) 
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.getsizeof(list(range(100)))
1008
>>> sys.getsizeof([i for i in range(100)])
912

ОНОВЛЕННЯ No2

Тест з Python 2.7.12:

Python 2.7.12 (default, Jul  1 2016, 15:12:24) 
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.getsizeof(list(xrange(100)))
1016
>>> sys.getsizeof([i for i in xrange(100)])
920

Question 2

Я думаю, ви бачите моделі перерозподілу, це зразок із джерела :

/* 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);

Друкуючи розміри списку довжинами 0-88, ви можете побачити збіги шаблонів:

# 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)

Результати (формат (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))

Надмірне розподіл здійснюється з міркувань продуктивності, дозволяючи спискам рости, не виділяючи більше пам’яті з кожним зростанням (краща амортизована продуктивність).

Ймовірною причиною різниці з використанням розуміння списку є те, що розуміння списку не може детерміновано обчислити розмір створеного списку, але list()може. Це означає, що розуміння будуть постійно нарощувати список, оскільки він заповнює його, використовуючи надмірне розподіл, до остаточного заповнення.

Можливо, це не призведе до зростання буфера надмірного розподілу з невикористаними виділеними вузлами, як тільки це буде зроблено (насправді, в більшості випадків це не буває, що перемогло б ціль перерозподілу).

list(), однак, він може додати деякий буфер незалежно від розміру списку, оскільки він знає остаточний розмір списку заздалегідь.

Ще одним підтвердженням, також із джерела, є те, що ми бачимо, як застосовується розуміння спискуLIST_APPEND , що вказує на використання list.resize, що, в свою чергу, вказує на споживання буфера попереднього розподілу, не знаючи, скільки його буде заповнено. Це відповідає поведінці, яку ви спостерігаєте.

На закінчення list()буде попередньо виділено більше вузлів як функція від розміру списку

>>> sys.getsizeof(list([1,2,3]))
60
>>> sys.getsizeof(list([1,2,3,4]))
64

Розуміння списку не знає розміру списку, тому він використовує операції додавання по мірі зростання, вичерпуючи буфер попереднього розподілу:

# 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

Question 3

Дякую усім за допомогу мені зрозуміти цей чудовий Python.

Я не хочу робити таке масове запитання (саме тому я публікую відповідь), просто хочу показати та поділитися своїми думками.

Як правильно зазначив @ReutSharabani : "list () детерміновано визначає розмір списку". Ви можете бачити це на цьому графіку.

Коли ви appendабо використовуєте розуміння списку, ви завжди маєте певні межі, які розширюються, коли ви досягаєте певної точки. І у list()вас майже однакові межі, але вони плаваючі.

ОНОВЛЕННЯ

Тож завдяки @ReutSharabani , @tavo , @SvenFestersen

Підводячи підсумок: list()попереднє розподіл пам'яті залежить від розміру списку, розуміння списку не може цього зробити (він вимагає більше пам'яті, коли це потрібно, наприклад .append()). Тому list()зберігайте більше пам'яті.

Ще один графік, який показує list()попередній розподіл пам'яті. Отже, зелена лінія показує list(range(830))додавання елемента за елементом і на деякий час пам’ять не змінюється.

ОНОВЛЕННЯ 2

Як зазначав @Barmar у коментарях нижче, list()мені потрібно швидше, ніж розуміння списку, тому я побіг timeit()із number=1000довжиною listвід 4**0до 4**10і результати