[Python-Dev] A new JIT compiler for a faster CPython?

[Amaury Forgeot d'Arc]

2012/7/18 Nick Coghlan <ncoghlan at gmail.com>:
> On the cpyext front, it would be rather helpful if developers interested in
> a high speed Python interpreter with good C extension compatibility worked
> with Dave Malcolm on his static analyser for Python C extensions. One of the
> reasons cpyext has trouble is that many refcounting bugs in extensions
> aren't fatal on CPython’s due to additional internal references - a refcount
> of 1 when it should be 2 is survivable in a way that 0 vs 1 is not.

It's not only about bugs. Even when reference counts are correctly
managed, cpyext is slow:

- each time an object crosses the C|pypy boundary, there is a dict lookup (!)

- each time a new object is passed or returned to C, a PyObject
structure must be allocated
(and sometime much more, specially for strings and types). Py_DECREF
will of course
free the PyObject, so next time will allocate the object again.

- borrowed references are a nightmare.

> Get rid of that drudgery from hacking on cpyext and it becomes significantly
> easier to expand the number of extensions that will work across multiple
> implementations of the API.

There are also some extension modules that play tricky games with the API;
PyQt for example uses metaclasses with a custom tp_alloc slot, to have access
to the PyTypeObject structure during the construction of the type...
The Python C API is quite complete, but some use cases are still
poorly supported.

-- 
Amaury Forgeot d'Arc