[pypy-dev] sys._getframe(1).f_locals is very slow on PyPy 1.8

[Maciej Fijalkowski]

On Sun, May 27, 2012 at 2:27 PM, Makoto Kuwata <kwa at kuwata-lab.com> wrote:

> Hi Maciej,
>
> On Sun, May 27, 2012 at 7:45 PM, Maciej Fijalkowski <fijall at gmail.com>
> wrote:
> > Hi Makoto.
> >
> > sys._getframe(1).f_locals will stay slow. The reason for this is that you
> > have to create all the locals and put them in a dictionary (they normally
> > don't even exist on the heap). Because of that we decided the JIT should
> > simply bail out and give up trying to optimize this particular code.
>
> I agree to PyPy team's decision.
> Some points may be slower on PyPy, but almost of all is much faster
> than CPython.
>
>
> > Note
> > that as documented on the python website, this functionality is mostly
> for
> > implementing debuggers and such (where speed does not matter), do you
> > *really* need your callers locals?
>
> Yes. I need to access to caller's local variables in my product (=
> Tenjin template engine)
> and sys._getframe() is reasonable solution for it (at least in CPython).
>
>
> > Sounds like a very deep magic to me, I
> > can point you to this presentation [1] as to why it might be a bad idea.
> >
> > [1].. http://www.youtube.com/watch?v=8e0l_Dt28MQ
>
> I know that sys._getframe() is kind of black magic, but I must use it
> because it is only the way to access to caller's local variables.
>
> My goal is to access to caller's local variables, and sys._getframe() is
> just a way to reach to goal.
>

My point is mostly that style-wise the design decision that led you to "I
need to inspect the callers variables" was probably not a very good one.
It's very tempting to use black magic, because writing explicit passing of
arguments is too verbose, but remember that explicit is always better than
implicit. I won't try to convince you any more - it's more about style than
about what can or cannot be made fast on pypy.

Cheers,
fijal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20120527/4994fe5d/attachment.html>