If you are looking for speed tacking an event loop on an interpreted scripting language is trying to dig a hole with a rake.
Its why the demand for such functionality was almost wholly absent from Python, PHP, etc for so long. Asyncio is a throughput boon even in a single core environment, which dates its practicality back to the 90s - and it was found there, in pretty much every graphics stack and COM. C apis have used what is fundamentally a promise since the 80s,
But if you are in a situation where you want those kinds of performance characteristics where you have work to do during blocking operations you probably don't want to be writing that code in an interpreted language to begin with.
Last week I was optimizing some performance critical Python but when considering my options I just ported the whole thing to Boost / C++ and got an ~80x speedup over the whole loop.
Theres only a narrow range of problems actually best solved with interpreted asyncio, pretty much only in the space where introducing a build system and doing language binding isn't worth it but the gains from being non-blocking are. They exist, and its definitely not a bad thing to have async support in your interpreted language, but it definitely isn't mission critical in the slightest.
Cani you please elaborate a bit how python Async await is crappy ? Not defending anything but I'm curious. Is it in the language or its implementation ? I've found the loop choices and relationship with dbus loop or other internal libraries cumbersome on Linux but that is implementation.
Its why the demand for such functionality was almost wholly absent from Python, PHP, etc for so long. Asyncio is a throughput boon even in a single core environment, which dates its practicality back to the 90s - and it was found there, in pretty much every graphics stack and COM. C apis have used what is fundamentally a promise since the 80s,
But if you are in a situation where you want those kinds of performance characteristics where you have work to do during blocking operations you probably don't want to be writing that code in an interpreted language to begin with.
Last week I was optimizing some performance critical Python but when considering my options I just ported the whole thing to Boost / C++ and got an ~80x speedup over the whole loop.
Theres only a narrow range of problems actually best solved with interpreted asyncio, pretty much only in the space where introducing a build system and doing language binding isn't worth it but the gains from being non-blocking are. They exist, and its definitely not a bad thing to have async support in your interpreted language, but it definitely isn't mission critical in the slightest.