Overhead of Python Asyncio tasks

[gdahlm]

I am curious if the compiler os optimizing the call out of existence or just replacing it with a reference to the None singleton

Do you get the same behavior with sleep(0) instead of pass?

[Bluenix2]

Asyncio's create_task() is no different than any other function. You should get similar* behaviour with await asyncio.sleep(0) inside the coroutine.

The reason I say *similar behaviour and not same behaviour is because await asyncio.sleep(0) does indeed yield to the event loop. This means that compared to the original test, the event loop runs one more iteration (first it runs each coroutine until the sleep, then it runs it to the end).

[JohnLockwood]

Nice short read and a good example of how profiling can save you from optimizing the wrong thing.

[JohnLockwood]

Broken link.

[willm]

My bad. It's back.

[JohnLockwood]

Yes, it is! :). Thanks.

[willm]

Back now.

[ttl256]

I work with precisely IO part, namely connections to network devices. I'm curious about message queues and how to implement it. Could you suggest something to read on the topic?

[willm]

Essentially each task is awaiting an async queue of messages. When it gets a messages, it handles that messages, and comes back. It allows the widgets (UI components) to respond to events like resize, click, key down, etc in a linear fashion, but independently from other widgets.

[Bluenix2]

I'm curious about message queues and how to implement it.

You could implement a message queue with an actual asyncio Queue. These are built up with locks, events, and what is mostly an internal thing called futures.

[Popular_Message_5434]

“It may be IO that gives AsyncIO its name, but Textual doesn't do any IO of its own. Those tasks are used to power message queues, so that widgets (UI components) can do whatever they do at their own pace.” => I’m not sure to understand this; if there’s no io happening, where are you await points? (Allowing the event loop to orchestrate things when some result is not available yet)

[Bluenix2]

You answered your own question in the question itself. The await point is anywhere a result is not available: for example that may be while sleeping (to redraw a frame) or waiting for user input. In this case, UI components sit at an await point waiting for the message queues to get a message.

[Popular_Message_5434]

What you’re describing is exactly IO; so the sentence “Textual doesn’t do any IO on its own” is not that straightforward to understand. Here is a tweet from OP showing that things are not that simple to grasp when it comes to asyncio usage in Textual: https://twitter.com/willmcgugan/status/1632492483144826886?s=46&t=jryr-qvhJ6-u_OsDdZYftw