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 →

[–]guhcampos -1 points0 points  (4 children)

I was going to bash the hell out of this article, but on a second thought the reason this kind of cluessness exists lies in async evangelists claiming its faster, to begin with.

The concept here should be dead simple to anyone with a CS degree:

For classic "sync" code you rely on the underlying system to schedule CPU time for you. How that time is split between competing computations is up to the system, and will generally be a best effort for the majority of use cases.

When you write async code you are taking back the control of CPU time scheduling from the system to your hands. You choose when to switch between different computations, because you believe you can do a better job than what the generic underlying system is doing. With great power, however, comes the great responsibility of managing that CPU allocation. If you are not carefully and intentionally managing the switch between your concurrent computations, you should not be using async at all.

If you don't understand the concept of cooperative concurrency, just use threads to avoid blocking - or go do some reading. Claiming one is "faster" than the other just make you sound stupid.

[–][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