3 ms·
I enjoyed this article from Cal Paterson my excolleague. It's about Python async not being faster: https://calpaterson.com/async-python-is-not-faster.html http
by samsquire 3y ago
I enjoyed this article from Cal Paterson my excolleague. It's about Python async not being faster:
https://calpaterson.com/async-python-is-not-faster.html https://calpaterson.com/async-python-is-not-faster.html
I think the idea is that while your blocking waiting for IO in one task you can serve a different task, potentially from a different user. Coroutines, green threads, communicating sequential processes as in Go or Occam.
- jerf 3y agoPure Python is a very slow language compared to Rust, with significant differences in orders of magnitudes of expenses. I would not expect information about Python performance to be particularly relevant to Rust without further evidence directly from Rust.
- galangalalgol 3y agoI think in retrospect, it makes sense to me that if you are io bound vs cpu bound (like my stuff usually is) that async could let you wait on more things at a time.
- jerf 3y agoI think the whole "IO bound" thing has taken on a life of its own and attained a legendary status that is not always an accurate reflection of reality. People often seem to model things as if "waiting on the DB" is all their system does and the code they wrote executes in exactly 0 nanoseconds, but that's not how it works. It isn't actually that hard to talk to a relatively local database with some well-optimized query and be doing CPU work either comparable to the wait you spent on the DB, or even greatly exceeding it, at which point your language's performance in fact does matter, potentially even dominates.