bpo-43574: Dont overallocate list literals

Lib/test/test_list.py

@@ -196,6 +196,15 @@ def test_preallocation(self):
         self.assertEqual(iter_size, sys.getsizeof(list([0] * 10)))
         self.assertEqual(iter_size, sys.getsizeof(list(range(10))))
 
+    @cpython_only
+    def test_overallocation(self):
+        iterable = [1,2]
+        self.assertEqual(sys.getsizeof(iterable), sys.getsizeof(list(iterable)))
+
+        # bpo-43574: Don't overallocate for list literals
+        iterable = [1,2,3]
+        self.assertEqual(sys.getsizeof(iterable), sys.getsizeof(list(iterable)))
+
     def test_count_index_remove_crashes(self):
         # bpo-38610: The count(), index(), and remove() methods were not
         # holding strong references to list elements while calling

Objects/listobject.c

@@ -58,25 +58,28 @@ list_resize(PyListObject *self, Py_ssize_t newsize)
         return 0;
     }
 
-    /* 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().
-     * Add padding to make the allocated size multiple of 4.
-     * The growth pattern is:  0, 4, 8, 16, 24, 32, 40, 52, 64, 76, ...
-     * Note: new_allocated won't overflow because the largest possible value
-     *       is PY_SSIZE_T_MAX * (9 / 8) + 6 which always fits in a size_t.
-     */
-    new_allocated = ((size_t)newsize + (newsize >> 3) + 6) & ~(size_t)3;
-    /* Do not overallocate if the new size is closer to overallocated size
-     * than to the old size.
-     */
-    if (newsize - Py_SIZE(self) > (Py_ssize_t)(new_allocated - newsize))
-        new_allocated = ((size_t)newsize + 3) & ~(size_t)3;
+    if (newsize == 0 || Py_SIZE(self) == 0) {
+        /* Don't overallocate for lists that start empty or are set to empty. */
+        new_allocated = newsize;
+    } else {
+        /* 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().
+         * Add padding to make the allocated size multiple of 4.
+         * The growth pattern is:  0, 4, 8, 16, 24, 32, 40, 52, 64, 76, ...
+         * Note: new_allocated won't overflow because the largest possible value
+         *       is PY_SSIZE_T_MAX * (9 / 8) + 6 which always fits in a size_t.
+         */
+        new_allocated = ((size_t)newsize + (newsize >> 3) + 6) & ~(size_t)3;
+        /* Do not overallocate if the new size is closer to overallocated size
+         * than to the old size.
+         */
+        if (newsize - Py_SIZE(self) > (Py_ssize_t)(new_allocated - newsize))
+            new_allocated = ((size_t)newsize + 3) & ~(size_t)3;
+    }
 
-    if (newsize == 0)
-        new_allocated = 0;
     num_allocated_bytes = new_allocated * sizeof(PyObject *);
     items = (PyObject **)PyMem_Realloc(self->ob_item, num_allocated_bytes);
     if (items == NULL) {