On Fri, 2 Sep 2016 at 17:37 MRAB <[email protected]> wrote: > On 2016年09月02日 23:45, Brett Cannon wrote: > > > > > > On Fri, 2 Sep 2016 at 15:11 Chris Angelico <[email protected] > > <mailto:[email protected]>> wrote: > > > > On Sat, Sep 3, 2016 at 7:56 AM, Brett Cannon <[email protected] > > <mailto:[email protected]>> wrote: > > > On Fri, 2 Sep 2016 at 13:31 Dino Viehland via Python-Dev > > > <[email protected] <mailto:[email protected]>> 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).
_______________________________________________ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com