[Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

[Brett Cannon]

On Mon, 29 Aug 2016 at 15:12 Maciej Fijalkowski <fijall at gmail.com> wrote:

> Hi Brett
>
> For what is worth, vmprof and similar tools would love such field
> (there is an open question how can you use vmprof *and* another tool,
> but later)
>

That's great to hear! Glad the solution has multiple use-cases.

-Brett


>
> On Mon, Aug 29, 2016 at 11:38 PM, Brett Cannon <brett at python.org> wrote:
> > For quick background for those that don't remember, part of PEP 523
> proposed
> > adding a co_extra field to code objects along with making the frame
> > evaluation function pluggable
> > (https://www.python.org/dev/peps/pep-0523/#expanding-pycodeobject). The
> idea
> > was that things like JITs and debuggers could use the field as a scratch
> > space of sorts to store data related to the code object. People who
> objected
> > to the new field did either for memory ("it adds another pointer to the
> > struct that won't be typically used"), or for conceptual reasons ("the
> code
> > object is immutable and you're proposing a mutable field"). The latter is
> > addressed by not exposing the field in Python and clearly stating that
> code
> > should never expect the field to be filled.
> >
> > For the former issue of whether the memory was worth it, Dino has been
> > testing whether the field is necessary for performance from a JIT
> > perspective. Well, Dino found the time to test Pyjion without the
> co_extra
> > field and it isn't pretty. With the field, Pyjion is faster than stock
> > Python in 15 benchmarks
> > (https://github.com/Microsoft/Pyjion/tree/master/Perf). Removing the
> > co_extra field and using an unordered_map from the C++ STL drops that
> number
> > to 2. Performance is even worse if we try and use a Python dictionary
> > instead.
> >
> > That means we still want to find a solution to attach arbitrary data to
> code
> > objects without sacrificing performance. One proposal is what's in PEP
> 523
> > for the extra field. Another option is to make the memory allocator for
> code
> > objects pluggable and introduce a new flag that signals that the object
> was
> > created using a non-default allocator. Obviously we prefer the former
> > solution due to its simplicity. :)
> >
> > Anyway, we would like to get this settled this week so that I can get
> > whatever solution we agree to (if any) in next week in time for Python
> 3.6b1
> > feature freeze that would be greatly appreciated.
> >
> > _______________________________________________
> > Python-Dev mailing list
> > Python-Dev at python.org
> > https://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe:
> > https://mail.python.org/mailman/options/python-dev/fijall%40gmail.com
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20160829/1b0c6c1b/attachment.html>