[Python-Dev] On the METH_FASTCALL calling convention (original) (raw)

Stefan Behnel stefan_ml at behnel.de
Sun Jul 8 03:34:53 EDT 2018

Jeroen Demeyer schrieb am 08.07.2018 um 09:07:

On 2018-07-07 10:55, Serhiy Storchaka wrote:

The first part of handling arguments can be made outside of the C function, by the calling API. Sure, it could be done but I don't see the advantage. I don't think you will gain performance because you are just moving code from one place to another.

You probably can, by allowing the caller to decide how to map the keyword arguments. Passing them as a flat array is the fastest way for the callee to evaluate them, so that's great. For the caller, they might already be available in that format or not, so the caller can save time if they are, and only needs to invest time if they are not.

And how do you plan to deal with *args and **kwds in your proposal? You'll need to make sure that this doesn't become slower.

That, on the other hand, is an actual concern. If we already have a tuple and dict, unpacking them for the call and then repacking them on the other side is a serious performance regression – for this specific use case.

The question is, how important is that use case compared to everything else? And, since we have more than one supported signature anyway, can we leave that case to a non-fastcall case? In the end, it's up to the callee to decide which protocol to support and use, and if the intention is to work with **kwargs, then maybe the callee should not use the fastcall protocol in the first place.

Stefan

More information about the Python-Dev mailing list