[Python-Dev] Looking for master thesis ideas involving Python
Jeremy Hylton
jeremy at alum.mit.edu
Wed Oct 29 23:24:10 EST 2003
On Wed, 2003-10-29 at 13:48, Phillip J. Eby wrote:
> At 06:33 PM 10/29/03 +0000, Michael Hudson wrote:
> >"Phillip J. Eby" <pje at telecommunity.com> writes:
> >
> > > * Direct use of positional arguments on the stack as the "locals" of
> > > the next function called, without creating (and then unpacking) an
> > > argument tuple, in the case where there are no */** arguments
> > > provided by the caller.
> >
> >Already done, unless I misunderstand your idea. Well, the arguments
> >might still get copied into the new frame's locals area but I'm pretty
> >sure no tuple is involved.
>
> Hm. I thought that particular optimization only could take place when the
> function lacks default arguments. But maybe I've misread that part. If
> it's true in all cases, then argument tuple creation isn't where the
> overhead is coming from.
There is an optimization that depends on having no default arguments (or
keyword arguments or free variables). It copies the arguments directly
from the caller's frame into the callee's frame without creating an
argument tuple.
It's interesting to avoid the copy from caller to callee, but I don't
think it's a big cost relative to everything else we're doing to set up
a frame for calling. (I expect the number of arguments is usually
small.) You would need some way to encode what variables are loaded
from the caller stack and what variables are loaded from the current
frame. Either a different opcode or some kind of flag in the current
LOAD/STORE argument.
One other possibility for optimization is this XXX comment in
fast_function():
/* XXX Perhaps we should create a specialized
PyFrame_New() that doesn't take locals, but does
take builtins without sanity checking them.
*/
f = PyFrame_New(tstate, co, globals, NULL);
PyFrame_New() does a fair amount of work that is unnecessary in the
common case.
Jeremy
More information about the Python-Dev
mailing list