6 ms·

Yeah except nodejs will beat flask in this same exact benchmark. Explain that.

jinglebells 6y ago
Nodejs is faster than Python as a general rule, anyway. As I understand, Nodejs compiles Javascript, Python interprets Python code. I do a lot of Django and Nodejs and Django is great to sketch an app out, but I've noticed rewriting endpoints in Nodejs directly accessing postgres gets much better performance. Just my 2c
- arghwhat 6y ago
  CPython, the reference implementation, interprets Python. PyPy interprets and JIT compiles Python, and more exotic things like Cython and Grumpy statically compiles Python (often through another, intermediate language like C or Go). Node.js, using V8, interprets and JIT compiles JavaScript. Although note that, while Node.js is fast relative to Python, it's still pretty slow. If you're writing web-stuff, I'd recommend Go instead for casually written, good performance.
- 1337shadow 6y ago
  The compare between Django against no-ORM is a bit weird given that rewriting your endpoint in python without Django or ORM would also have produced better results I suppose.
- crimsonalucard1 6y ago
  Right but this test focused on concurrent IO. The bottleneck is not the interpreter but the concurrency model. It doesn't matter if you coded it in C++, the JIT shouldn't even be a factor here because the bottleneck is IO and therefore ONLY the concurrency model should be a factor here. You should only see differences in speed based off of which model is used. All else is negligible. So you have two implementations of async that are both bottlenecked by IO. One is implemented in node. The other in python. The node implementation behaves as expected in accordance to theory meaning that for thousands of IO bound tasks it performs faster then a fixed number of sync worker threads (say 5 threads). This makes sense right? Given thousands of IO bound tasks, eventually all 5 threads must be doing IO and therefore blocked on every task, while the single threaded async model is always context switching whenever it encounters an IO task so it is never blocked and it is always doing something... Meanwhile the python async implementation doesn't perform in accordance to theory. 5 async workers is slower then 5 sync workers on IO bound tasks. 5 sync workers should eventually be entirely blocked by IO and the 5 async workers should never be blocked ever... Why is the python implementation slower? The answer is obvious: It's python specific. It's python that is the problem.
arghwhat 6y ago
JIT compiler.
- crimsonalucard1 6y ago
  Bottleneck is IO. Concurrency model should be the limiting factor here. NodeJS is faster than flask because of the concurrency model and NOT because of the JIT. The python async implementation being slower than the python sync implementation means one thing: Something is up with python. The poster implies that with the concurrency model the outcome of these tests are expected. The reality is, these results are NOT expected. Something is going on specifically with the python implementation.
talideon 6y ago
CPython doesn't have a JIT, while node.js does. If you want to compare apples to apples, try looking at Flask running on PyPy.
- e12e 6y ago
  Ed: after reading the article, I guess it's safe to say that everything below is false :) --- I'd guess the c++ event loop is more important than the jit? Maybe a better comparison is quart (with eg uvicorn) https://pgjones.gitlab.io/quart/ https://pgjones.gitlab.io/quart/ https://www.uvicorn.org/ https://www.uvicorn.org/ Or Sanic / uvloop? https://sanicframework.org/ https://sanicframework.org/ https://github.com/MagicStack/uvloop https://github.com/MagicStack/uvloop
  - talideon 6y ago
    You're not completely off. There might be issues with async/await overhead that would be solved by a JIT, but also if you're using asyncio, the first _sensible_ choice to make would be to swap out the default event loop with one actually explicitly designed to be performant, such as uvloop's one, because asyncio.SelectorEventLoop is designed to be straightforward, not fast. There's also the major issue of backpressure handling, but that's a whole other story, and not unique to Python. My major issue with the post I replied to is that there are a bunch of confounding issues that make the comparison given meaningless.
  - Tronic2 6y ago
    Plain sanic runs much faster than the uvicorn-ASGI-sanic stack used in the benchmark, and the ASGI API in the middle is probably degrading other async frameworks' performance too. But then this benchmark also has other major issues, like using HTTP/1.0 without keep-alive in its Nginx proxy_pass config (keep-alive again has a huge effect on performance, and would be enabled on real performance-critical servers). https://sanic.readthedocs.io/en/latest/sanic/nginx.html https://sanic.readthedocs.io/en/latest/sanic/nginx.html
    - e12e 6y ago
nurettin 6y ago
You mean express.js ?
- crimsonalucard1 6y ago
  NodeJS primitives are enough to produce the same functionality as flask without the need for an extra framework.

Nodejs is faster than Python as a general rule, anyway. As I understand, Nodejs compiles Javascript, Python interprets Python code. I do a lot of Django and Nodejs and Django is great to sketch an app out, but I've noticed rewriting endpoints in Nodejs directly accessing postgres gets much better performance. Just my 2c

arghwhat 6y ago
CPython, the reference implementation, interprets Python. PyPy interprets and JIT compiles Python, and more exotic things like Cython and Grumpy statically compiles Python (often through another, intermediate language like C or Go). Node.js, using V8, interprets and JIT compiles JavaScript. Although note that, while Node.js is fast relative to Python, it's still pretty slow. If you're writing web-stuff, I'd recommend Go instead for casually written, good performance.
1337shadow 6y ago
The compare between Django against no-ORM is a bit weird given that rewriting your endpoint in python without Django or ORM would also have produced better results I suppose.
crimsonalucard1 6y ago
Right but this test focused on concurrent IO. The bottleneck is not the interpreter but the concurrency model. It doesn't matter if you coded it in C++, the JIT shouldn't even be a factor here because the bottleneck is IO and therefore ONLY the concurrency model should be a factor here. You should only see differences in speed based off of which model is used. All else is negligible. So you have two implementations of async that are both bottlenecked by IO. One is implemented in node. The other in python. The node implementation behaves as expected in accordance to theory meaning that for thousands of IO bound tasks it performs faster then a fixed number of sync worker threads (say 5 threads). This makes sense right? Given thousands of IO bound tasks, eventually all 5 threads must be doing IO and therefore blocked on every task, while the single threaded async model is always context switching whenever it encounters an IO task so it is never blocked and it is always doing something... Meanwhile the python async implementation doesn't perform in accordance to theory. 5 async workers is slower then 5 sync workers on IO bound tasks. 5 sync workers should eventually be entirely blocked by IO and the 5 async workers should never be blocked ever... Why is the python implementation slower? The answer is obvious: It's python specific. It's python that is the problem.

arghwhat 6y ago

JIT compiler.

crimsonalucard1 6y ago
Bottleneck is IO. Concurrency model should be the limiting factor here. NodeJS is faster than flask because of the concurrency model and NOT because of the JIT. The python async implementation being slower than the python sync implementation means one thing: Something is up with python. The poster implies that with the concurrency model the outcome of these tests are expected. The reality is, these results are NOT expected. Something is going on specifically with the python implementation.

talideon 6y ago

CPython doesn't have a JIT, while node.js does. If you want to compare apples to apples, try looking at Flask running on PyPy.

e12e 6y ago
Ed: after reading the article, I guess it's safe to say that everything below is false :) --- I'd guess the c++ event loop is more important than the jit? Maybe a better comparison is quart (with eg uvicorn) https://pgjones.gitlab.io/quart/ https://pgjones.gitlab.io/quart/ https://www.uvicorn.org/ https://www.uvicorn.org/ Or Sanic / uvloop? https://sanicframework.org/ https://sanicframework.org/ https://github.com/MagicStack/uvloop https://github.com/MagicStack/uvloop
- talideon 6y ago
  You're not completely off. There might be issues with async/await overhead that would be solved by a JIT, but also if you're using asyncio, the first _sensible_ choice to make would be to swap out the default event loop with one actually explicitly designed to be performant, such as uvloop's one, because asyncio.SelectorEventLoop is designed to be straightforward, not fast. There's also the major issue of backpressure handling, but that's a whole other story, and not unique to Python. My major issue with the post I replied to is that there are a bunch of confounding issues that make the comparison given meaningless.
- Tronic2 6y ago
  Plain sanic runs much faster than the uvicorn-ASGI-sanic stack used in the benchmark, and the ASGI API in the middle is probably degrading other async frameworks' performance too. But then this benchmark also has other major issues, like using HTTP/1.0 without keep-alive in its Nginx proxy_pass config (keep-alive again has a huge effect on performance, and would be enabled on real performance-critical servers). https://sanic.readthedocs.io/en/latest/sanic/nginx.html https://sanic.readthedocs.io/en/latest/sanic/nginx.html
  - e12e 6y ago

nurettin 6y ago

You mean express.js ?

crimsonalucard1 6y ago
NodeJS primitives are enough to produce the same functionality as flask without the need for an extra framework.