Callback vs Promise vs Async/Await

callback-vs-promise-vs-async-await

Callback vs Promise vs Async/Await benchmarks

info

Benchmark Files
https://github.com/petkaantonov/bluebird/tree/master/benchmark

Platform Info
Linux 5.13.0-40-generic x64
Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz × 4

Summary
In terms of performance and memory usage, there is no alternative to callbacks. 
Promise and async/await are slower and use more resources. 

node-v16

ls ./doxbee-sequential/*.js | sed -e 's|\.js||' | xargs node ./performance.js --p 1 --t 1 --n 10000

results for 10000 parallel executions, 1 ms per I/O op

file                                    time(ms)  memory(MB)
callbacks-baseline                           329       24.58
callbacks-caolan-async-waterfall             420       50.55
callbacks-suguru03-neo-async-waterfall       426       41.49
promises-bluebird-generator                  499       42.61
promises-native-async-await                  558       56.47
promises-bluebird                            570       50.09
promises-ecmascript6-native                  614       67.87
promises-lvivski-davy                        622       91.29
promises-cujojs-when                         705       67.07
promises-then-promise                        782       75.79
generators-tj-co                             804       59.77
promises-tildeio-rsvp                        911       91.99
promises-calvinmetcalf-lie                  1099      141.34
promises-dfilatov-vow                       1445      141.14
promises-obvious-kew                        1471      104.65
observables-pozadi-kefir                    1499      146.91
streamline-generators                       1540       77.86
promises-medikoo-deferred                   1758      132.80
streamline-callbacks                        2190      102.14
observables-Reactive-Extensions-RxJS        2732      218.70
promises-kriskowal-q                        5838      359.06
observables-caolan-highland                 6688      488.01
observables-baconjs-bacon.js               10233      761.92

Platform info:
Linux 5.13.0-40-generic x64
Node.JS 16.14.0
V8 9.4.146.24-node.20
Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz × 4

ls ./madeup-parallel/*.js | sed -e 's|\.js||' | xargs node ./performance.js --p 25 --t 1 --n 10000

results for 10000 parallel executions, 1 ms per I/O op

file                                   time(ms)  memory(MB)
callbacks-baseline                          624       82.00
callbacks-suguru03-neo-async-parallel       719       88.20
promises-bluebird                          1037      105.51
promises-lvivski-davy                      1099      156.89
callbacks-caolan-async-parallel            1141      116.48
promises-bluebird-generator                1198      106.91
promises-cujojs-when                       1391      157.09
promises-ecmascript6-native                2280      212.14
generators-tj-co                           2289      225.09
promises-native-async-await                2346      218.36
promises-then-promise                      2358      235.82
promises-calvinmetcalf-lie                 2927      330.71
promises-tildeio-rsvp                      3006      315.84
promises-medikoo-deferred                  3859      356.98
promises-dfilatov-vow                      5261      476.34
promises-obvious-kew                       5971      657.50
streamline-generators                     14209      857.03
streamline-callbacks                      20183     1066.83

Platform info:
Linux 5.13.0-40-generic x64
Node.JS 16.14.0
V8 9.4.146.24-node.20
Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz × 4

github doesn't give me a place to "thumbs up" your reply, however, "thumbs up" :)

Hello, I wanted to report back an interesting finding that occurred for me. I was preparing to replace async-await with callbacks in a js-defined runtime/state-machine and decided to first write benchmarks. That runtime is constructed around async-await (or callbacks) and is a very worthy and "real-world" performance-test of both callback and async-await approaches.

I wrote benchmarks using the same style benchmark.js method above. The first benchmark I wrote resolved "deep" values with the existing async-runtime. The second benchmark resolved the same values, using a separately modified copy of the runtime with callbacks rather than async-await.

Surprisingly to me, there was no performance difference between the two. If the benchmark was configured to run both tests many many times (40,000 times) then callbacks were seen to have a small performance benefit, but otherwise no practical difference between them.

I personally believe this more-recent benchmark over the older one shared here about a year ago and have basically decided to stop using callbacks. Possibly the callback test shared here about a year ago was too trivial and fell into some trivial-condition nodejs is optimized for.

Anyway, anyone facing this question should be encouraged to use benchmarks and verify things themselves before moving ahead.

An additional factor for me, code written around async-await will be more easily ported to different languages. When javascript has been fully vandalised and undermined, it will be a little easier to move over to whatever comes next.

If the benchmark was configured to run both tests many many times (40,000 times) then callbacks were seen to have a small performance benefit, but otherwise no practical difference between them.

Thanks for an update! It seems that v8 and nodejs team done a great job ensuring we won't use outdated callback style anymore.

thanks for the thanks :)

Nice 👍