C-API Capsule for _asynciomodule.c aka _asyncio and implementing more asyncio objects in CPython

[Vizonex]

I felt the need to bring up this idea I had for the future that involves getting rid of some more expensive bottlenecks. As a low level programmer who works with asyncio heavily this has been a pretty big problem I've been facing currently.

The biggest bottle-kneck I have been facing is that there is no way to improve the speed of the objects in Cython or C in General. I have projects such as winloop [which is a windows version of uvloop] that deals with asyncio in Cython. But the biggest bottle-kneck with this project at the moment is that it's making too many costly calls when interacting with asyncio which I would like to reduce to just using C calls for more parts of code such as Future objects or asyncio.Handle objects with the cdef extension classes tied to them.

Couple months ago I discovered that Having Python Capsules improves performance and speed of calls and since I've recently worked with a few such as Multidict which is still an ongoing pull request I decided to see if CPython would be willing to explore making an C-API capsule for _asynciomodule.c in the future.

Also made an experimental project of exposing asyncio's internals into a different repo which I am using to attempt to experiment to see if a C-API would improve asyncio's current performance but also putting Handles (aka asyncio.Handle) as well as timer handles into CPython would also be a good idea since that would allow uvloop & winloop to use asyncio handles as a cdef extension in Cython in the future. But feel free to criticize me if this idea is a bad approach all together or if anybody has other comments on this idea that I came up with.

[Valmarelox]

I also considered this issue - I recently profiled FastAPI servers to identify optimization opportunities, and what I observed is that slot_tp_richcompare on TimerHandle objects appears to be a significant CPU time sink.
I'm unsure yet whether moving the implementation to C would provide a significant improvement, but I'll give it a try as well.

[Vizonex]

I also considered this issue - I recently profiled FastAPI servers to identify optimization opportunities, and what I observed is that slot_tp_richcompare on TimerHandle objects appears to be a significant CPU time sink. I'm unsure yet whether moving the implementation to C would provide a significant improvement, but I'll give it a try as well.

My reason for requesting the handles to be optimized in C is due to c extension classes in Cython since uvloop/winloop wrap Handles and having a cdef class would help with it's optimizations, but this is also a pretty good reason as well.