osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Python-Dev] Register-based VM [Was: Possible performance regression]


On Tue, Feb 26, 2019 at 3:56 PM Neil Schemenauer <nas-python at arctrix.com>
wrote:

> Right.  I wonder though, could we avoid allocating the Python frame
> object until we actually need it?  Two situations when you need a
> heap allocated frame come to mind immediately: generators that are
> suspended and frames as part of a traceback.  I guess
> sys._getframe() is another.  Any more?
>
>
I've been thinking about that as well...  I think in some ways the easy
part of
this is actually the easy part of this is the reification of the frame it's
self.  You
can have a PyFrameObject which is just declared on the stack and add a new
field to it which captures the address of the PyFrameObject* f (e.g.
PyFrameObject **f_stackaddr).  When you need to move to aheap allocated
one you copy everything over as you say and update *f_stackaddr to point
at the new heap address.

It seems a little bit annoying with the various levels of indirection from
the
frame getting created in PyEval_EvalCodeEx and flowing down into
_PyEval_EvalFrameDefault - so there may need to be some breakage there for
certain low-level tools.  I'm also a little bit worried about things which
go looking
at PyThreadState and might make nasty assumptions about the frames already
being heap allocated.

FYI IronPython does support sys._getframe(), you just need to run it with a
special flag (and there are various levels - e.g. -X:Frames and
-X:FullFrames,
the latter which guarantees your locals are in the frame too).  IronPython
is more
challenged here in that it always generates "safe" code from a CLR
perspective
and tracking the address of stack-allocated frame objects is therefore
challenging (although maybe more possible now then before with various C#
ref
improvements).

I'm not sure exactly how much this approach would get though...  It seems
like
the frame caches are pretty effective, and a lot of the cost of them is
initializing
them / decref'ing the things which are still alive in them.  But it doesn't
seem a
like a super complicated change to try out...  It's actually something I'd
at least
like to try prototyping at some point.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20190226/8e39ff59/attachment-0001.html>