On 2016-09-02 23:45, Brett Cannon wrote:
On Fri, 2 Sep 2016 at 15:11 Chris Angelico <ros...@gmail.com
<mailto:ros...@gmail.com>> wrote:
On Sat, Sep 3, 2016 at 7:56 AM, Brett Cannon <br...@python.org
<mailto:br...@python.org>> wrote:
> On Fri, 2 Sep 2016 at 13:31 Dino Viehland via Python-Dev
> <python-dev@python.org <mailto:python-dev@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.
_______________________________________________
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
