Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

should we choose async await over Promise in Javascript

I know that the async await is the new Promise in the town and it is a new way to write asynchronous code and I also know that

We didn’t have to write .then, create an anonymous function to handle the response

Async/await makes it finally possible to handle both synchronous and asynchronous errors with the same construct, good old try/catch

The error stack returned from a promise chain gives no clue of where the error happened. However, the error stack from async/await points to the function that contains the error

AND SO ON...

but here I have done a simple bench mark https://repl.it/repls/FormalAbandonedChimpanzee

In the benchmark I have run 2 loops for 1 million times. In first loop I am calling a function that is returning 1 in another function I am calling a function that is throwing 1 as an exception.

the time taken by first loop which is calling a function that is returning 1 is almost half of the function that is throwing 1 as error.

Which shows that time taken by throw is almost double of the time taken by return

node v7.4 linux/amd64

return takes 1.233seconds
1000000
throw takes 2.128seconds
1000000

Benchmark Code Below

function f1() {
  return 1;
}

function f2() {
  throw 1;
}

function parseHrtimeToSeconds(hrtime) {
    var seconds = (hrtime[0] + (hrtime[1] / 1e9)).toFixed(3);
    return seconds;
}

var sum = 0;
var start = 0;
var i = 0;

start = process.hrtime();
for (i = 0; i < 1e6; i++) {
  try {
    sum += f1();
  } catch (e) {
    sum += e;
  }
}
var seconds = parseHrtimeToSeconds(process.hrtime(start));
console.log('return takes ' + seconds + 'seconds');
console.log(sum);




sum = 0;
start = process.hrtime();
for (i = 0; i < 1e6; i++) {
  try {
    sum += f2();
  } catch (e) {
    sum += e;
  }
}

seconds = parseHrtimeToSeconds(process.hrtime(start));
console.log('throw takes ' + seconds + 'seconds');
console.log(sum);
like image 424
Vikas Bansal Avatar asked Nov 28 '17 05:11

Vikas Bansal


3 Answers

As most things go, the answer is "it depends".

Before talking about performance, the more important aspect is the maintainability of the code, and limitation of async/await vs raw Promise.

async/await is a great way to execute asynchronous code sequentially, while Promise enables you to run asynchronous code concurrently.

async function foo() {
  const a = await backend.doSomething()
  const b = await backend.doAnotherThing()
  return a + b
}

In the code above, backend.doAnotherThing() will not be executed until backend.doSomething() has returned. On the other hand:

function foo() {
  Promise.all([backend.doSomething(), backend.doAnotherThing()])
    .then(([a, b]) => {
       return a + b
    })
}

will execute both calls, and wait for both to complete.

As you mentioned about the benefits of async/await, I personally use it extensively. Except for the cases above.

If you need performance and to you, the performance difference between async/await vs Promise is more important than the readability benefit of async/await over Promise, by all mean go ahead.

As long as it is a conscious choice, you should be fine.

UPDATE: as mentioned by Derek 朕會功夫

You can get parallel execution with async/await by:

async function foo() {
  const p1 = backend.doSomething()
  const p2 = backend.doAnotherThing()
  return await p1 + await p2
}
like image 61
unional Avatar answered Oct 22 '22 14:10

unional


Your benchmark has nothing to do with the performance between async/await vs raw promises. All I can see is that throwing an error takes a longer time to compute. This is expected.

Back to the main question, should use async/await rather than .then with raw promises?

Keep in mind that async/await is merely syntactic sugar over raw promises, so there shouldn't be much impact on the overall performance. However, it does make your code more linear which removes a lot of cognitive overhead from the developer.

The conclusion is use what you prefer. Promises can be polyfill'd but new syntaxes cannot, so you might want to keep that in mind when deciding which style to use.


Some misunderstanding:

The error stack returned from a promise chain gives no clue of where the error happened

That is not true. A quick check with:

function error() {
    return new Promise(function(res, rej) {
        res(undefined()); // uh oh
    });
}

error().then(console.log, e => console.log("Uh oh!", e.stack));

shows the entire error stack including the location.

like image 28
Derek 朕會功夫 Avatar answered Oct 22 '22 15:10

Derek 朕會功夫


Building on unional's answer:

You can achieve the same behavior as Promise.all with async/await

function foo() {
  Promise.all([backend.doSomething(), backend.doAnotherThing()])
    .then(([a, b]) => {
       return a + b
    })
}

async function foo() {
  const a = backend.doSomething()
  const b = backend.doAnotherThing()
  return await a + await b
}

Backend tasks happen concurrently and we wait on both to be finished before we return. See also the MDN example I wrote

Based on this I am not sure if there is any performance advantage to directly using Promises over async/await.

like image 44
spygi Avatar answered Oct 22 '22 13:10

spygi