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

Brett Cannon brett at python.org
Mon Aug 29 19:15:14 EDT 2016

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 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20160829/1b0c6c1b/attachment.html>

More information about the Python-Dev mailing list