0

Are there any performance gains of resolving Promises via Promise.all(), compared to doing so sequentially?

Example:

// I understand that this always resolves sequentially via blocking.
await promise1;
await promise2;

// Here promises can resolve in any order. Is this any better/faster than the above?
await Promise.all([promise1, promise2])

Trying to understand what's the best approach for concurrency in JS. Thanks in advance.

EDIT:Duplicate of this.

My take-aways:

  • key advantage is the fail-fast behavior of Promise.all(). In that regards, there is a performance benefit - however it's negligible. The other is better error handling.
  • always use Promise.all() for scheduling multiple concurrent operations.
  • 1
    `await` does not involve blocking. – Pointy Apr 30 '21 at 14:06
  • Where are those promises created? Notice that it's not `await` that resolves them. – Bergi Apr 30 '21 at 14:10
  • 1
    `Promise.all` does not improve performance. It's the "not waiting for the first promise before starting the second task" that improves performance (if done correctly). `Promise.all` is just the correct way to wait for multiple promises at once. – Bergi Apr 30 '21 at 14:12
  • 2
    Does this answer your question? [Any difference between await Promise.all() and multiple await?](https://stackoverflow.com/questions/45285129/any-difference-between-await-promise-all-and-multiple-await) – m_wer Apr 30 '21 at 14:12
  • `await` is absolutely not blocking. It's asynchronous code written like synchronous code, that's the beauty of it. Basically it's syntactic sugar for Promises. – Jeremy Thille Apr 30 '21 at 14:17
  • @JeremyThille My understanding is that it does block until the Promise is resolved/rejected. From Mozilla blog post (https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Asynchronous/Async_await): "The await keyword blocks execution of all the code that follows it until the promise fulfills, exactly as it would with a synchronous operation." – Aleksander Nowak Apr 30 '21 at 15:28
  • @AleksanderNowak That "blog" article on MDN is a wiki, and can be wrong. In this case, it really should say "*… **suspends** execution of the code inside the `async function` until …*". The term "blocking" has a quite well-defined meaning, and it's not doing that, since other code (outside of the `async function`) will continue to run. – Bergi Apr 30 '21 at 15:32
  • @Bergi Thanks for the help. You answered my question with the same conclusions I had. Cheers. – Aleksander Nowak Apr 30 '21 at 15:40
  • It blocks the execution of the code that's below, yes, that's the whole point. That is why you can do `const a = await asyncFunction(); console.log(a);`. But it does not block the _thread_. All other operations keep going in the meantime. I have put together a quick example [here](https://codepen.io/jeremythille/pen/YzNoeGm?editors=0011). I launch a repetitive task, then I await a Promise for 5 seconds. During these 5 seconds, _the repetitive task keeps running_, proof that the thread is not blocked. When the Promise resolves, then the code execution keeps going. That's the whole point. – Jeremy Thille May 01 '21 at 06:11

0 Answers0