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

[Maciej Fijalkowski]

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)

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
>