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 <br...@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 > _______________________________________________ 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/archive%40mail-archive.com