Hacker News new | ask | show | jobs
by aliceryhl 2099 days ago
This doesn't seem true. My mental model says that although synchronous may require somewhat fewer resources when there are few connections, async will win as the number of connections increase.

To illustrate this, consider the cost of spawning a new thread. The stack of a thread is usually a few MB, but lets use 1 MB for simplicity. Then 1000 concurrent connections is 1 GB of memory just for stack space.

With async/await, you don't pay a megabyte per connection because async uses perfectly sized stacks that are typically much much smaller than a megabyte.

Of course you can cap the number of connections, but IO speed puts an upper limit on how fast you can serve a connection, which means that the cap limits the number of connections you can serve per second.

Additionally, I doubt that the overhead at a few connections is large. There's a reason people call async/await a zero-cost abstraction, even if using a runtime such as Tokio introduces some amount of cost.

1 comments

Just going off what I remember from when async started to stabilise, see the top comment on this reddit thread. It may be be fixed by now or simply just allocated memory instead but many were commenting on it at the time.

https://old.reddit.com/r/rust/comments/cych6a/async_performa...

There was a bug regarding the size of async functions growing exponentially in certain cases at some point, but it should have been fixed now.