2018-07-07 10:55 GMT+02:00 Serhiy Storchaka :
> There is my idea. Split every of keyword argument parsing functions on two
> parts. The first part linearize keyword arguments, it converts positional
> and keyword arguments (in whatever form they were presented) into a linear
> array of PyObject*
2018-07-07 0:26 GMT+02:00 Victor Stinner :
> I designed FASTCALL with the help of Serhiy for keywords. I prepared a long
> email reply, but I found an opportunity for optimisation on **kwargs and I
> need time to see how to optimize it.
I just created: "Python function call optimization: avoid
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
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
Hi Serhiy!
Serhiy Storchaka schrieb am 07.07.2018 um 10:55:
> There is my idea. Split every of keyword argument parsing functions on two
> parts. The first part linearize keyword arguments, it converts positional
> and keyword arguments (in whatever form they were presented) into a linear
> array
On Sat, Jul 7, 2018 at 12:19 AM, Stefan Behnel wrote:
> Typically, it's calls with 1 to ~3 positional arguments that occur in
> performance critical situations. Often just one, rarely more, and zero
> arguments is a fast case anyway. Keyword arguments will always suffer some
> kind of penalty
of keyword parameter
names as an attribute of CFunction.
I don't know whether this ides is vital or dead, but I' going to try it.
And implementing it will change the METH_FASTCALL|METH_KEYWORDS calling
convention a lot.
___
Python-Dev mailing list
Python
Jeroen Demeyer schrieb am 05.07.2018 um 16:53:
> The only case when this handling of keywords is suboptimal is when using
> **kwargs. In that case, a dict must be converted to a tuple. It looks hard
> to me to support efficiently both the case of fixed keyword arguments
> (f(foo=x)) and a keyword
On Sat, Jul 7, 2018 at 7:29 AM Victor Stinner wrote:
>
> Hi,
>
> I designed FASTCALL with the help of Serhiy for keywords. I prepared a long
> email reply, but I found an opportunity for optimisation on **kwargs and I
> need time to see how to optimize it.
>
> Maybe there is a need for passing
Hi,
I designed FASTCALL with the help of Serhiy for keywords. I prepared a long
email reply, but I found an opportunity for optimisation on **kwargs and I
need time to see how to optimize it.
Maybe there is a need for passing **kwargs as a dict at C level, but use
FASTCALL for positional
On 2018-07-06 06:07, INADA Naoki wrote:
Maybe, one way to improve METH_FASTCALL | METH_KEYWORDS can be this.
kwds can be either tuple or dict.
But that would be just pushing the complexity down to the callee. I'd
rather have a simpler protocol at the expense of a slightly more complex
I don't know Serhiy's idea about how METH_FASTCALL | METH_KEYWORDS
calling convention can be improved in the future.
When I reading PEP 580, I liked your Py PyCCall_FastCall signature.
Maybe, one way to improve METH_FASTCALL | METH_KEYWORDS can be this.
kwds can be either tuple or dict.
---
I'm not the world's leading expert on Python bytecode anymore, but unless
there's something I'm missing your conclusion looks eminently reasonable,
and so I expect you'll get very little traction on this thread. (If you had
wanted to get a megathread you should have written "FASTCALL considered
Hello all,
As discussed in some other threads ([1], [2]), we should discuss the
METH_FASTCALL calling convention.
For passing only positional arguments, a C array of Python objects is
used, which is as fast as it can get. When the Python interpreter calls
a function, it builds that C array
14 matches
Mail list logo
