well when the magical quantum computing show drops, this will be obsolete. threading is so 2 dimensional thinking.
i hate the overall design concept of threading. it's not just Python that's bad at it, it's evident in most languages that thread management is not bad because of the implementation, it's bad because systemically the design of process threads is clumsy and not at all simple or graceful.
Possible discussion around this blog post and whole premise of it is anyway byproduct and misleading. Without knowing, mentioning and thinking before CPU cores, about CPU vector instructions, how properly access memory cache layers and align data without cache misses, how to design data structures for this. Without all this and more, it is all just like to chase one's tail; to mill the wind; to plough the sand.
>For a typical web application, a significant percentage of the total time a request takes will be spent in Python (rendering a template, for example) - the amount of time spent reading-from and writing-to the database driver socket, for example, is often negligible.
Huh? In what planet? Rendering a template takes negligible time compared to the IO latencies to read from the database (even for a fast simple query) or a cold file on the filesystem.
This (and not the extra v8 speed) is why a single process Node.js server gets great performance for a typical web app, better than anything single process but synchronous Python could ever dream of -- and that a blocking Node.js would fall back to Python-level performance for web serving scenario.
>Whether they're actually going fast or not is anyone's guess. The best you're likely to see is some dubious graph from a half-baked benchmark.
Dubious compared to what? The "take my word for it, it is bad" blogger opinion?
It really depends on what you're doing. In my experience it's quite common for moderately complex python web services to be mostly CPU bound if you put the database server on the same machine.
If you're talking to a regular sql database you'll usually find the database itself limits concurrency so there's little advantage to async io over threading. You really only see the advantage of async io in proxy like scenarios or where you're managing thousands of long lived connections (web sockets etc.)
There was a thread about "why is async in Rust useful" because it's not better for latency or throughput, and essentially the answer was "because you can't cancel threads immediately". If you need that, you need an event loop (async). If not, threads are the best and always have been.
> The bottom-line is that if I were tasked with implementing a server that must handle thousands of concurrent users (or substitute your other favorite async use-case), I would pick gevent or a tool like golang over asyncio every time.
Me too!
If I have to remember to add await and async to avoid accidentally breaking my code, why don't I just write in Go instead? At least I get some safety checks from the compiler.
8 comments
[ 87.3 ms ] story [ 799 ms ] threadi hate the overall design concept of threading. it's not just Python that's bad at it, it's evident in most languages that thread management is not bad because of the implementation, it's bad because systemically the design of process threads is clumsy and not at all simple or graceful.
Huh? In what planet? Rendering a template takes negligible time compared to the IO latencies to read from the database (even for a fast simple query) or a cold file on the filesystem.
This (and not the extra v8 speed) is why a single process Node.js server gets great performance for a typical web app, better than anything single process but synchronous Python could ever dream of -- and that a blocking Node.js would fall back to Python-level performance for web serving scenario.
>Whether they're actually going fast or not is anyone's guess. The best you're likely to see is some dubious graph from a half-baked benchmark.
Dubious compared to what? The "take my word for it, it is bad" blogger opinion?
If you're talking to a regular sql database you'll usually find the database itself limits concurrency so there's little advantage to async io over threading. You really only see the advantage of async io in proxy like scenarios or where you're managing thousands of long lived connections (web sockets etc.)
And mainly it is because it is all or nothing. It is a terrible design that we are now stuck with...
Me too! If I have to remember to add await and async to avoid accidentally breaking my code, why don't I just write in Go instead? At least I get some safety checks from the compiler.