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

Maciej Fijalkowski fijall at gmail.com
Mon Aug 29 18:12:25 EDT 2016

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 coextra 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 coextra 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 coextra field and using an unorderedmap 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

More information about the Python-Dev mailing list