[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>
> 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
this is actually the easy part of this is the reification of the frame it's
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
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
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
the latter which guarantees your locals are in the frame too). IronPython
challenged here in that it always generates "safe" code from a CLR
and tracking the address of stack-allocated frame objects is therefore
challenging (although maybe more possible now then before with various C#
I'm not sure exactly how much this approach would get though... It seems
the frame caches are pretty effective, and a lot of the cost of them is
them / decref'ing the things which are still alive in them. But it doesn't
like a super complicated change to try out... It's actually something I'd
like to try prototyping at some point.
-------------- next part --------------
An HTML attachment was scrubbed...