Currently, reference implementation of PEP 649 has been suspended.
We need to revive it and measure performance/memory impact.

Perhaps this sounds strange--but I don't actually agree.

PEP 563 was proposed to solve a forward-references problem for the typing community.  If you read the PEP, you'll note it contains no discussion about its impact on CPU performance or memory consumption.  The performance of its prototype was fine, and in any case, the important thing was to solve the problem in the language.

I think PEP 649 should be considered in the same way.  In my opinion, the important thing is to figure out what semantics we want for the language.  Once we figure out what semantics we want, we should implement them, and only then should we start worrying about performance.  Fretting about performance at this point is premature and a distraction.

I assert PEP 649's performance and memory use is already acceptable, particularly for a prototype.  And I'm confident that if PEP 649 is accepted, the core dev community will find endless ways to optimize the implementation.

As far as I remember, the reference implementation created a function
object for each methods.

First, it's only for methods with annotations.  Second, it only stores a code object on the annotated function; the co_annotations function is lazily created.  The exception to this is when co_annotations needs a closure; in that case, it currently creates and binds the co_annotation function non-lazily.  Obviously this could be done lazily too, I didn't bother for the prototype.

/arry