[Python-Dev] Idea for a fast calling convention (original) (raw)

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 PyArgParseTupleXXX calls, which could be replaced by less general, optimized versions. I tried that some time ago, when python-dev first talked about METHO. I did a script that looks for these PyArgParseTuple(args, "xxx", ...) calls and replace them with some in-line equivalent, e.g. "PyTupleGETSIZE(args) == 2 && PyTupleGETITEM(args, 0)->obtype == etc. && etc.". It didn't pay out. The METHO optimization was a much better one. It seems that PyArgParseTuple() isn't just called often enough in practice now. BTW this remark also applies to the proposals for METHSTACK 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