DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

Cover image for Speed up your code with Promise.all
David Morrow
David Morrow

Posted on • Updated on

Speed up your code with Promise.all

So one of the things I see commented on all the time in Javascript code reviews.

Say you have some code as such...

async function myFunction() {
  await someThing();
  await someOtherThing();
  await yetAnotherThing();
}
Enter fullscreen mode Exit fullscreen mode

Do we need to each of these one at a time? Cant we fork this and call them all together?

What being pointed out here is that we have to wait on each one of these Promises to return before the next one can start.

One of the most amazing things about working with Javascript is its concurrency. Meaning it can run your code in parallel instead of waiting for each Promise to finish before moving starting the next. Commonly referred to as "forking".

Using Promise.all vs await each

Since this ability is so powerful, lets make sure we are using it. Let's take a look at the example above and see how we can make that run in parallel.

function delayedResponse() {
  return new Promise((resolve, reject) => {
    setTimeout(resolve, 1000);
  });
}

async function time(label, fn) {
  const start = new Date();
  await fn();
  console.log(
    (new Date() - start) / 1000, `seconds to load ${label}`
  );
}

time("sequential", async () => {
  await delayedResponse();
  await delayedResponse();
  await delayedResponse();
});

time("parallel", async () => {
  await Promise.all([
    delayedResponse(), 
    delayedResponse(), 
    delayedResponse()
  ]);
});

Enter fullscreen mode Exit fullscreen mode

Ok, here is some code that we can test this idea with. I have a function that returns a Promise that takes 1sec to resolve.

function delayedResponse() {
  return new Promise((resolve, reject) => {
    setTimeout(resolve, 1000);
  });
}
Enter fullscreen mode Exit fullscreen mode

and a function that times how long a function passed to it takes to run.

async function time(label, fn) {
  const start = new Date();
  await fn();
  console.log(
    (new Date() - start) / 1000, `seconds to load ${label}`
  );
}
Enter fullscreen mode Exit fullscreen mode

These are not important, I just wanted to explain what they were. The main thing that we are talking about here is the difference in speed with the two approaches we are timing here.

Ok lets run this code and see what happens.

1.002 seconds to load parallel
3.005 seconds to load sequential
Enter fullscreen mode Exit fullscreen mode

Whoah... that's almost 3 times as fast for the parallel one. Makes sense, as there are three calls and each one takes a second. You can see how this would greatly effect your performance if you had many Promises to wait on.

Say for example we had 6 calls instead of 3. What would the timing on that look like?

1.002 seconds to load parallel
6.009 seconds to load sequential
Enter fullscreen mode Exit fullscreen mode

You guessed it, twice as much on the difference.

Real world example

Say for example you have a front end app that makes a few API requests before it's ready to render and become interactive. This could make a HUGE difference to your users.

Capturing the responses

One of the common excuses I have seen for awaiting each Promise is that,

But I need to save each response from each Promise

async function () {
  const myData = await someApiCall();
  // do something with your data...
}
Enter fullscreen mode Exit fullscreen mode

You can still do that with Promise.all. Promise.all returns the results in an Array in the order that the Promises were invoked, not in the order that they resolve. This is a common misconception.

Ok lets test this idea.

function randomDuration() {
  const min = 500;
  const max = 1000;
  return Math.random() * (max - min) + min;
}

function delayedResponse(msg) {
  return new Promise((resolve, reject) => {
    setTimeout(resolve, randomDuration(), msg + ": done");
  });
}

async function time(label, fn) {
  const start = new Date();
  await fn();
  console.log(
    (new Date() - start) / 1000, `seconds to load ${label}`
  );
}

// the code we are benchmarking

async function sequential() {
  const res1 = await delayedResponse("first");
  const res2 = await delayedResponse("second");
  const res3 = await delayedResponse("third");
  console.log([res1, res2, res3]);
}

async function parallel() {
  const results = await Promise.all([
    delayedResponse("first"),
    delayedResponse("second"),
    delayedResponse("third"),
  ]);
  console.log(results);
}

time("sequential", sequential);
time("parallel", parallel);
Enter fullscreen mode Exit fullscreen mode

Ok the main difference here is that I am giving each Promise a random duration before it returns, between 1/2 and 1 second. That way I can show that they come back in the order invoked, not the order resolved.

[ 'first: done', 'second: done', 'third: done' ]
0.921 seconds to load parallel
[ 'first: done', 'second: done', 'third: done' ]
2.393 seconds to load sequential
Enter fullscreen mode Exit fullscreen mode

Notice that even though I randomized how long each Promise will take to resolve, the results array is in the order that I called them in. Fantastic.

Example where this won't work

There are some cases where you cannot call all your promises at the same time. Take for example API calls like I mentioned above. Say you need part of the result from one, before you can call the next.

For example say you are using REST routes that are nested...

async function () {
  const user = await Api.getUser();
  const account = await Api.getAccount(user.id);
  const articles = await Api.getArticles(user.id);
}
Enter fullscreen mode Exit fullscreen mode

Well, you cant call all these together, but you may be able to still group some. Just do the best you can :)

async function () {
  const user = await Api.getUser();
  const [account, articles] = await Promise.all([
    Api.getAccount(user.id),
    Api.getArticles(user.id)
  ]);
}
Enter fullscreen mode Exit fullscreen mode

Promise.all vs Promise.allSettled

One very important thing to note, If ANY of the promises reject. Promise.all will reject at the first failure. Think of it as fail fast.

If you need to handle each rejection, and need a response for every Promise no matter what happens, use Promise.allSettled instead of Promise.all

Top comments (5)

Collapse
 
charlesr1971 profile image
Charles Robertson

But the whole point about:

async/await
Enter fullscreen mode Exit fullscreen mode

Is that we create an order of execution. The call runs asynchronously but, the next call has to wait until it finishes.
In a way, you get the best of both worlds.

If I want pure asynchronicity, I would choose your approach.

But sometimes, it is good to be able to guarantee order, in an asynchronous world. πŸ™‚

Collapse
 
dperrymorrow profile image
David Morrow • Edited on

But the whole point about: async/await Is that we create an order of execution.

Agreed, and that is the case in the example I use the example where you need your data from the API before your client side application can run.

I'm just pointing out if you don't need to wait for each Promise to resolve prior to the next one, don't do that. It's an unnecessary performance killer.

This may seem obvious, but I wrote this post because I've see this performance pitfall often in PR reviews.

Collapse
 
charlesr1971 profile image
Charles Robertson

Yes. Absolutely agreed.
I would never use:

async/await 
Enter fullscreen mode Exit fullscreen mode

If I didn’t need to rely on the order of execution. πŸ™‚

Collapse
 
bacqueyrisses profile image
Enzo

Hey ! Great article.
I was wondering what's your theme on the screenshot ?
Thanks.

Collapse
 
dperrymorrow profile image
David Morrow

community material theme and I'm using the "ocean" variant. Ive been stuck on that one for a while, really like it.

Dream Big


Use any Linode offering to create something unique or silly in the DEV x Linode Hackathon 2022 and win the Wacky Wildcard category.

β†’ Join the Hackathon <-