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

[Brett Cannon]

On Fri, 2 Sep 2016 at 17:37 MRAB <python at mrabarnett.plus.com> wrote:

> On 2016-09-02 23:45, Brett Cannon wrote:
> >
> >
> > On Fri, 2 Sep 2016 at 15:11 Chris Angelico <rosuav at gmail.com
> > <mailto:rosuav at gmail.com>> wrote:
> >
> >     On Sat, Sep 3, 2016 at 7:56 AM, Brett Cannon <brett at python.org
> >     <mailto:brett at python.org>> wrote:
> >     > On Fri, 2 Sep 2016 at 13:31 Dino Viehland via Python-Dev
> >     > <python-dev at python.org <mailto:python-dev at python.org>> wrote:
> >     >>
> >     >> So it looks like both list and tuple are about within 5% of using
> >     co_extra
> >     >> directly.  Using a tuple instead of a list is about a wash except
> for
> >     >> make_v2 where list is 1.4x slower for some reason (which I didn't
> >     dig into).
> >     >>
> >     >> I would say that using a tuple and copying the tuple on updates
> makes
> >     >> sense as we don't expect these to change very often and we don't
> >     expect
> >     >> collisions to happen very often.
> >     >
> >     >
> >     > So would making co_extra a PyTupleObject instead of PyObject
> alleviate
> >     > people's worry of a collision problem? You're going to have to
> >     hold the GIL
> >     > anyway to interact with the tuple so there won't be any race
> >     condition in
> >     > replacing the tuple when it's grown (or initially set).
> >     >
> >
> >     I'm not following how this solves the collision problem. If you have
> a
> >     tuple, how do the two (or more) users of it know which index they're
> >     using? They'd need to keep track separately for each object, or else
> >     inefficiently search the tuple for an object of appropriate type
> every
> >     time. What am I missing here?
> >
> >
> > You're not missing anything, you just have to pay for the search cost,
> > otherwise we're back to square one here of not worrying about the case
> > of multiple users. I don't see how you can have multiple users of a
> > single struct field and yet not have to do some search of some data
> > structure to find the relevant object you care about. We've tried maps
> > and dicts and they were too slow, and we proposed not worrying about
> > multiple users but people didn't like the idea of either not caring or
> > relying on some implicit practice that  evolved around the co_extra
> > field. Using a tuple seems to be the best option we can come up with
> > short of developing a linked list which isn't that much better than a
> > tuple if you're simply storing PyObjects. So either we're sticking with
> > the lack of coordination as outlined in the PEP because you don't
> > imagine people using a combination of Pyjion, vmprof, and/or some
> > debugger simultaneously, or you do and we have to just eat the
> > performance degradation.
> >
> Could the users register themselves first? They could then be told what
> index to use.
>

But that requires they register before any tuple is created, else they run
the risk of seeing a tuple that was created before they registered. To
cover that issue you then have to check the length at which point it's no
more expensive than just iterating through a tuple (especially in the
common case of a tuple of length 1).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20160903/0f53ed78/attachment-0001.html>