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

[Brett Cannon]

On Fri, 2 Sep 2016 at 13:31 Dino Viehland via Python-Dev <
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).

-Brett


>
> > -----Original Message-----
> > From: Python-Dev [mailto:python-dev-
> > bounces+dinov=microsoft.com at python.org] On Behalf Of Chris Angelico
> > Sent: Tuesday, August 30, 2016 2:11 PM
> > To: python-dev <python-dev at python.org>
> > Subject: Re: [Python-Dev] Update on PEP 523 and adding a co_extra field
> to
> > code objects
> >
> > On Wed, Aug 31, 2016 at 4:55 AM, Serhiy Storchaka <storchaka at gmail.com>
> > wrote:
> > > On 30.08.16 21:20, Antoine Pitrou wrote:
> > >>
> > >> On Tue, 30 Aug 2016 18:12:01 +0000
> > >> Brett Cannon <brett at python.org> wrote:
> > >>>>
> > >>>> Why not make it always a list?  List objects are reasonably cheap
> > >>>> in memory and access time... (unlike dicts)
> > >>>
> > >>>
> > >>> Because I would prefer to avoid any form of unnecessary performance
> > >>> overhead for the common case.
> > >>
> > >>
> > >> But the performance overhead of iterating over a 1-element list is
> > >> small enough (it's just an array access after a pointer dereference)
> > >> that it may not be larger than the overhead of the multiple tests and
> > >> conditional branches your example shows.
> > >
> > >
> > > Iterating over a tuple is even faster. It needs one pointer
> > > dereference less.
> > >
> > > And for memory efficiency we can use just a raw array of pointers.
> >
> > Didn't all this kind of thing come up when function annotations were
> > discussed? Insane schemes like dictionaries with UUID keys and so on.
> > The decision then was YAGNI. The decision now, IMO, should be the same.
> > Keep things simple.
> >
> > ChrisA
> > _______________________________________________
> > Python-Dev mailing list
> > Python-Dev at python.org
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmail.pyt
> > hon.org%2fmailman%2flistinfo%2fpython-
> > dev&data=01%7c01%7cdinov%40microsoft.com%7c9d750b06b2134a2145c70
> > 8d3d11a4ab0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=szub1gs
> > DW2rdns3IQGV68J3tCqWiNcjqG77xYIfoORc%3d
> > Unsubscribe:
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmail.pyt
> > hon.org%2fmailman%2foptions%2fpython-
> > dev%2fdinov%2540microsoft.com&data=01%7c01%7cdinov%40microsoft.co
> > m%7c9d750b06b2134a2145c708d3d11a4ab0%7c72f988bf86f141af91ab2d7c
> > d011db47%7c1&sdata=TEzMSyJLmAe2BVZGPugXAh6bga2xN1WQw3bR0z0b
> > %2fLg%3d
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20160902/08a4327c/attachment.html>