[Python-Dev] Idea for a fast calling convention

Christian Tismer tismer at stackless.com
Mon Mar 1 14:23:34 EST 2004


Armin Rigo wrote:

> Hi Christian!
> 
> On Sat, Feb 28, 2004 at 07:12:54PM +0100, Christian Tismer wrote:
> 
>>p.s.: I believe some automatic source analysis and rewrite might
>>pay off in other areas as well. Grepping through the sources,
>>there are still very many similar patterns of PyArg_ParseTupleXXX
>>calls, which could be replaced by less general, optimized versions.
> 
> 
> I tried that some time ago, when python-dev first talked about METH_O.  I did
> a script that looks for these PyArg_ParseTuple(args, "xxx", ...) calls and
> replace them with some in-line equivalent, e.g. "PyTuple_GET_SIZE(args) == 2
> && PyTuple_GET_ITEM(args, 0)->ob_type == etc. && etc.".
> 
> It didn't pay out.  The METH_O optimization was a much better one.  It seems
> that PyArg_ParseTuple() isn't just called often enough in practice now.
> 
> BTW this remark also applies to the proposals for METH_STACK to avoid the
> tuple creation altogether.  What amount of time is really spent there?

Maybe a big profiling run could clarify if and where something
can be saved. It is also a relative measure:
If the function that I call takes up lots of computation time,
I won't care too much about parameter processing.
On the other hand, a candidate like len() is so cheap to compute
that it really would pay off (but that one is already taken, sure).

For METH_STACK, I'm not sure. Does it raise complication, or
does it make things even clearer?
 From my Stackless POV, throwing parameters into the callee and
not having to care about the arg tuple is much more
"continuation-like". I *would* have a problem with the current style
if the callee wouldn't increfs its parameters, anyway, so I'm allowed
to drop the arg tuple early. Fortunately here is some redundance
of refcounts.

I guess it has a little improvements not only by saving tuple
creation but also that many decrefs, probably not soo much.
A consequent implementation through the whole source seems to
be quite a lot of effort. Maybe a relative measure for some common
cases can give some figures?

ciao -  chris
-- 
Christian Tismer             :^)   <mailto:tismer at stackless.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  mobile +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/




More information about the Python-Dev mailing list