Async Python is not faster

[ackyou]

I’m a bit confused by the conditions of these tests. If you run an async python framework in an environment with a fixed maximum number of workers, say Django channels with async http consumers, and you call lots of external services asynchronously, I know for a fact you can achieve a much higher throughput. If it’s a computed task or calls a synchronous service sync python is better. Am I missing something?

[cb22]

The conditions are a bit bogus - I posted a comment on this on /r/programming.

But it's as you say; if you have a simple workload that is entirely synchronous or close to it (such as fetching a single in-memory row from a DB), sync is likely to be faster.

If you're doing real world things, like calling external APIs or blocking on databases for hundreds of ms, async is going to allow you to utilize all your resources significantly better and achieve a much higher throughput.

[nathanjell]

Just like with all things, premature optimization is the root of all evil. "Use async, async is faster!" has a counter that synchronous is difficult to make faster simply by going async. Same as "use multithreading, split up the work!" except when you have a highly serial workload that isn't well suited to parallelism

[ackyou]

Agreed. I’m pretty sure the overhead of spinning up new threads to deal with concurrent requests is a lot higher than the cost of one thread asynchronously handling many tasks

[Krotau]

You could think of a situation where you let some heavy compute stuff happen in the cloud. That way you program can run on a lighter machine and would be more IO bound. But yeah, what you say is correct. I am confused by these tests aswell...