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 sens
So I ran the tests with both a list and a tuple. They were about 5% slower on
a handful of benchmarks, and then the difference between the tuple and list
again had a few benchmarks that were around 5% slower. There was one benchmark
where the tuple one significantly for some reason (mako_v2) w
On Mon, Jun 20, 2016 at 12:59 PM, Brett Cannon
mailto:br...@python.org>> wrote:
MRAB's response made me think of a possible approach: the co_extra field could
be the very last field of the PyCodeObject struct and only present if a certain
flag is set in co_flags. This is similar to a trick used
Mark wrote:
> > Dino and I thought of two potential alternatives, neither of which we
> > have taken the time to implement and benchmark. One is to simply have
> > a hash table of memory addresses to JIT data that is kept on the JIT
> > side of things. Obviously it would be nice to avoid the overhe
Martin wrote:
> On 4 June 2016 at 06:11, Benjamin Peterson wrote:
> > PEP 7 requires CPython to use C code conforming to the venerable C89
> > standard. Traditionally, we've been stuck with C89 due to poor C
> > support in MSVC. However, MSVC 2013 and 2015 implement the key
> features of C99.
>
