Broad goals for 3.12 (and beyond)

[markshannon]

Fundamentals

• We can't speedup opaque blobs of C code.
  • And we don't want use some elaborate mechanism like RPython (PyPy) or sulong (GraalPython) to transform the C code.
• We can speedup code that runs in the interpreter
• We can reduce the overhead of memory management, by doing less of it, and by doing it more efficiently.
• Not doing something at all is always preferable to doing it faster.

This means that we want:

• C code to consist of builtin functions that are well typed and don't call back in Python (much).
• Everything else in bytecode (99.9% Python, but we might need a few key trampolines in hand written bytecode).
• To be able to execute Python code faster.
• To remove other overhead due to poor memory layout, reference counting and cycle GC.

C code to consist of builtin functions that are well typed and don't call back in Python (much).

This needs new calling convention(s) that allow us to do appropriate work (parsing arguments, etc) in the VM and leave the C code to do the real work. See #374

Speeding up the execution of Python code

This is the big one.
See #375

Removing incidental overhead due to poor memory layout, reference counting and cycle GC.

The cycle GC

We currently perform cycle collection too often, and not very effectively.
We should be able to fix this be using better triggers.

We could also reduce the overhead of tracing during GC with a more declarative model, or some parallelism and pre-fetching. This is likely to both harder and less profitable than just doing fewer collections.

Compact object headers

See #125

[ericsnowcurrently]

Also https://gist.github.com/markshannon/f51ba3dca24a891dc37d4ab7f3886098:

• Projected (short) trace based non-compiling optimizer
• Compact objects
• Finish specialization (hit rates for non-polymorphic code after startup > 98%)
• Declarative APIs for builtin functions and object layout.
• Improved cycle collector
• Reduced refcounting overhead