Based on the PR not really elaborating, it gives me the impression that there was an assumption that giving asyncio 5 tasks to execute would result in in them being executed concurrently, like an OS scheduler, rather than it executing the first task to completion or until it hits a blocking call, then moving on to the next, until it completes a task. The issue I'm seeing is that component logic is (currently) all non-async so there aren't going to be any blocking calls.

You could artificially add blocking calls (for example, asyncio.sleep(0)) to allow smaller tasks to finish ahead of larger ones, but it would incur the performance penalty of the context switching and possibly be slower in most circumstances. And actually, since the component logic isn't inside an async function, it's not really clear how you would do that.

On top of that, your largest components are probably the root components, which need to be rendered first anyways.

This goes back to "is it worth it?" There's an overhead to maintaining multiple code paths, and the extra complexity will add to the overhead performance cost.

One alternative idea is to give components an optional priority, which would allow them to jump in front of the others. Then instead of a queue you use a priority queue to figure out what to render next. This could be done by changing the _rendering_queue to a queue.PriorityQueue (or I suppose it's an asyncio.PriorityQueue in this context) which I think should work without having to do any finagling.

Not trying to shoot down work people have done, but it makes sense to justify these things before further work is spent on it if its not clear whether there's value in the first place.

It doesn't assume concurrent rendering, which is why I requested Ryan to change the name to async rendering.

A single ASGI worker can service thousands of components, which similarly can have thousands of effects and events.

By asyncifying more things, it allows us to queue other asyncio tasks (events, hooks, and ASGI send/receive events) in-between render operations.

A simpler way of putting it is: ASGI webservers have better throughput during high loads the more async yielding you provide. This is even more beneficial for event loop implementations such as uvloop.

Is the intent to change the components to be async? Is there some magic I am missing that is making them async in some way?

 async def _render_component(
 self,
 exit_stack: AsyncExitStack,
 old_state: _ModelState | None,
 new_state: _ModelState,
 component: ComponentType,
 ) -> None:
 ...
 raw_model = component.render() # no await, sync function

By asyncifying more things, it allows us to queue other asyncio tasks (events, hooks, and ASGI send/receive events) in-between render operations.

This is already happening with _serial_render

I haven't tested out the performance of Ryan's PR, but theoretically it should help throughput when dealing with multiple root components and lots of async effects.

I do 100% agree that ditching the protocols is a good idea. I've generally been annoyed with them, and would prefer base classes.

Several instances of protocol checks have been replaced with a base class within #1281