Recently, I modified call_method() and call_maybe() of Objects/typeobject.c to avoid the creation of a temporary tuple: replace Py_VaBuildValue()+PyObject_Call() with the new _PyObject_VaCallFunctionObjArgs().

But while working on the issue #28870, I noticed that _PyObject_VaCallFunctionObjArgs() is not efficient and can be avoided. In typeobject.c, the number of arguments is hardcoded, so we don't need complex functions to compute the number of arguments and decide to allocate an array on the stack or on the heap.

New changeset b9404639a18c by Victor Stinner in branch 'default':
call_method() now uses _PyObject_FastCall()
https://hg.python.org/cpython/rev/b9404639a18c

Full commit message:

changeset:   106081:b9404639a18c
tag:         tip
user:        Victor Stinner <victor.stinner@gmail.com>
date:        Wed Jan 11 00:07:40 2017 +0100
files:       Include/abstract.h Objects/abstract.c Objects/typeobject.c
description:
call_method() now uses _PyObject_FastCall()

Issue #29233: Replace the inefficient _PyObject_VaCallFunctionObjArgs() with
_PyObject_FastCall() in call_method() and call_maybe().

Only a few functions call call_method() and call it with a fixed number of
arguments. Avoid the complex and expensive _PyObject_VaCallFunctionObjArgs()
function, replace it with an array allocated on the stack with the exact number
of argumlents.

It reduces the stack consumption, bytes per call, before => after:

test_python_call: 1168 => 1152 (-16 B)
test_python_getitem: 1344 => 1008 (-336 B)
test_python_iterator: 1568 => 1232 (-336 B)

Remove the _PyObject_VaCallFunctionObjArgs() function which became useless.
Rename it to object_vacall() and make it private.