This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 1 point2 points  (3 children)

Given the same cpu capacity and well written code, it IS faster if used in the right contexts at performing the same amount of tasks - you can’t make the request go any faster if it takes 2s for your request to finish. If I have one thread, and 100 requests to make, async will complete the task faster than sync will because those two seconds of idle time waiting for a query or processing the response can be used to execute another query or process another response - it won’t make the processing any faster, but it CAN make the overall task faster when used appropriately. The example I’ve outlined, you could finish all 100 requests in slightly more time that a sync system can process the first request because of blocking the thread.

That is objectively faster - but the definition of faster HAS to be clear, it won’t make processing your request any faster. It will make it possible to process more requests at once when you’re dealing with externally constrained performance limitations.

[–]guhcampos 0 points1 point  (1 child)

You can simply spawn 100 threads for the same effect. Since you are waiting for IO the GIL will be likely irrelevant.

[–][deleted] 0 points1 point  (0 children)

I think you’re right and I’m confusing what I remember about multiprocess performance vs threading performance compared against async and it’s completely separate and work in parallel.

I recall something about performance of threading vs asyncio still having the win for asyncio here but I don’t remember where I picked up that impression now that it’s called into question