3 ms·

Promises and Async/Await are just too slow. I'll stick with Callbacks. https://kyrylkov.com/2017/04/25/native-promises-async-functions-nodejs-8-performance/ h

Promises and Async/Await are just too slow. I'll stick with Callbacks. https://kyrylkov.com/2017/04/25/native-promises-async-functions-nodejs-8-performance/ https://kyrylkov.com/2017/04/25/native-promises-async-functi...

sametmax 9y ago
How is that possible ? Await doesn't have this effect in python 3 and v8 is faster than cpython.
- saas_co_de 9y ago
  Promises require creating and modifying objects that contain the promise state which plain callbacks do not. The difference in micro-benchmarks can be huge: https://jsperf.com/native-promise-vs-callback https://jsperf.com/native-promise-vs-callback That example is a probably a worst case scenario because of how it is constructed, but on my MBP it still gets around 1M promises created and resolved per second. For a typical web app or api you will not see any benefit in using callbacks over async/await in your application code unless you are consistently doing something that requires 1000's of promises per request.
GhostVII 9y ago
Shouldn't we be more focused on which is easier to use though? Even if promises are slower, they probably aren't going to be a major performance issue, so I think if you find promises easier to use and less bug-prone, they are better regardless of preformance.
- sparrish 9y ago
  I don't think we should. I chose node over ruby because of performance. Those numbers are showing significant overhead for promises and async/await. That's a problem I don't want to inject into my latency-sensitive application.
- untog 9y ago
  > Shouldn't we be more focused on which is easier to use though? In JS I think this depends a lot on whether you are writing client-side code or not. Prioritizing developer ease of use over end-user performance is a very bad habit to get into. But it matters less when writing code that'll run in Node. (that said, I'm not at all convinced that the performance difference mentioned in this article matters a whole lot. It's not actually that significant.)
  - GhostVII 9y ago
    > Prioritizing developer ease of use over end-user performance is a very bad habit to get into Why is that? Whenever you use a high level language, you are making development easier at the cost of end-user performance. Or using a foreach loop instead of a regular for loop, is usually a bit slower, but makes development easier and less bug prone. Premature optimisation is the root of all evil and all that. Obviously at some point you have to prioritise end-user performance, when making decisions that will have a big impact on performance, but when making decisions on the level of promises vs callbacks, I don't think end-user performance should be a priority.
chmln 9y ago
Keep in mind that these microbenchmarks are run with N=10000, which mostly renders the 600ms total latency difference insignificant. Its also highly likely that the gap will become minimal over time. If that's still a non-negligible difference, I don't see why one wouldn't just write a server in something like go instead. Node isn't the best choice for a performance-sensitive application.
- rmrfrmrf 9y ago
  Not to mention whatever task you’re actually doing inside the Promise will be an order of magnitude slower than settling the Promise itself.
tengbretson 9y ago
"Programs must be written for people to read, and only incidentally for machines to execute"

sametmax 9y ago

How is that possible ? Await doesn't have this effect in python 3 and v8 is faster than cpython.

saas_co_de 9y ago
Promises require creating and modifying objects that contain the promise state which plain callbacks do not. The difference in micro-benchmarks can be huge: https://jsperf.com/native-promise-vs-callback https://jsperf.com/native-promise-vs-callback That example is a probably a worst case scenario because of how it is constructed, but on my MBP it still gets around 1M promises created and resolved per second. For a typical web app or api you will not see any benefit in using callbacks over async/await in your application code unless you are consistently doing something that requires 1000's of promises per request.

GhostVII 9y ago

Shouldn't we be more focused on which is easier to use though? Even if promises are slower, they probably aren't going to be a major performance issue, so I think if you find promises easier to use and less bug-prone, they are better regardless of preformance.

sparrish 9y ago
I don't think we should. I chose node over ruby because of performance. Those numbers are showing significant overhead for promises and async/await. That's a problem I don't want to inject into my latency-sensitive application.
untog 9y ago
> Shouldn't we be more focused on which is easier to use though? In JS I think this depends a lot on whether you are writing client-side code or not. Prioritizing developer ease of use over end-user performance is a very bad habit to get into. But it matters less when writing code that'll run in Node. (that said, I'm not at all convinced that the performance difference mentioned in this article matters a whole lot. It's not actually that significant.)
- GhostVII 9y ago
  > Prioritizing developer ease of use over end-user performance is a very bad habit to get into Why is that? Whenever you use a high level language, you are making development easier at the cost of end-user performance. Or using a foreach loop instead of a regular for loop, is usually a bit slower, but makes development easier and less bug prone. Premature optimisation is the root of all evil and all that. Obviously at some point you have to prioritise end-user performance, when making decisions that will have a big impact on performance, but when making decisions on the level of promises vs callbacks, I don't think end-user performance should be a priority.

chmln 9y ago

Keep in mind that these microbenchmarks are run with N=10000, which mostly renders the 600ms total latency difference insignificant. Its also highly likely that the gap will become minimal over time. If that's still a non-negligible difference, I don't see why one wouldn't just write a server in something like go instead. Node isn't the best choice for a performance-sensitive application.

rmrfrmrf 9y ago
Not to mention whatever task you’re actually doing inside the Promise will be an order of magnitude slower than settling the Promise itself.

tengbretson 9y ago

"Programs must be written for people to read, and only incidentally for machines to execute"