RetroSearch Browse

Sun Jul 8 03:34:53 EDT 2018 · https://mail.python.org/pipermail/python-dev/2018-July/154509.html

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2018-July/154509.html below:

[Python-Dev] On the METH_FASTCALL calling convention