list_resize is a long function that probably won't get inlined. But for the vast majority of cases in list.append, we just need to check whether the list is big enough (not whether it's small enough, or whether it's null or the wrong type), then insert and update the size. This can be inlined, with an actual call only taking place whenever we need to resize.

We can also add a reference-consuming version of PyList_Append to elide an INCREF/DECREF pair.

Hmm. Would you measure benefit from inlining and skipping incref/decref separately?

If benefit of inlining is very small, making _PyList_AppendTakeRef() as regular internal API looks better to me.

The attached _PyList_AppendTakeRef.diff has the ceval.c, but this implementation:

int
_PyList_AppendTakeRef(PyListObject *self, PyObject *newitem)
{
    assert(self != NULL && newitem != NULL);
    assert(PyList_Check(self));
    Py_ssize_t len = PyList_GET_SIZE(self);
    Py_ssize_t allocated = self->allocated;
    assert((size_t)len + 1 < PY_SSIZE_T_MAX);
    if (allocated > len) {
        PyList_SET_ITEM(self, len, newitem);
        Py_SET_SIZE(self, len + 1);
        return 0;
    }
    if (list_resize(self, len + 1) < 0) {
        Py_DECREF(newitem);
        return -1;
    }
    PyList_SET_ITEM(self, len, newitem);
    return 0;
}

Results:

Thank you. I agree that inlining is worth enough.

But we already inlined too many functions in ceval and there is an issue caused by it... (bpo-45116)

New changeset a0ea7a1 by Dennis Sweeney in branch 'main':
bpo-47009: Streamline list.append for the common case (GH-31864)
a0ea7a1

New changeset 6c6e040 by Dennis Sweeney in branch 'main':
bpo-47009: Let PRECALL_NO_KW_LIST_APPEND do its own POP_TOP (GH-32239)
6c6e040

New changeset 9e88b57 by Christian Heimes in branch 'main':
bpo-47009: Fix assert on big endian (GH-32332)
9e88b57

Buildbots are passing, so I'm closing this. Thanks for the catch and fix!