CALL_FUNCTION_EX argument passing routine can be improved for vectorcalls
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 77.2k
- Forks
- 36k
- PR merge metrics
- PR metrics pending
Description
While working on https://github.com/python/cpython/issues/95126, I noticed that CALL_FUNCTION_EX for vectorcall Python functions is extremely wasteful. These are its steps:
CALL_FUNCTION_EXcallsdo_call_corewith aargstuple andkwargsdict.- Eventually it's detected that the function supports vectorcall, and it calls
_PyVectorcall_Call. This calls_PyStack_UnpackDict, which unpacks theargstuple andkwargsdict into a C array. - This C array is passed to the vectorcall function. Eventually calling
_PyEval_Vector. _PyEval_Vectorcalls_PyEvalFramePushAndInit, which sees that there's complex args, and recreates the tuple and args dict ininitialize_localsfrom the C array.- Frame is pushed and evaluated, then popped. End.
We shouldn't even be converting the arguments to a C array just to vectorcall. We should instead directly transfer ownership of args tuple and kwds dict because that would be significantly faster in this case (and save us the tuple and dict recreation dance).
CC @markshannon and @brandtbucher .
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Trace the argument flow through do_call_core, _PyVectorcall_Call, _PyStack_UnpackDict, _PyEval_Vector, _PyEvalFramePushAndInit, and initialize_locals. First understand how CALL_FUNCTION_EX reaches vectorcall Python functions and how ownership is handled at each boundary. Done means the path avoids the intermediate C array and tuple/dict recreation while preserving correct argument ownership and behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- compilers
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100