On Mon, 29 Aug 2016 at 15:12 Maciej Fijalkowski <fij...@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 <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
