(original) (raw)

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@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@python.org
\> https://mail.python.org/mailman/listinfo/python-dev
\> Unsubscribe:
\> https://mail.python.org/mailman/options/python-dev/fijall%40gmail.com
\>