5 ms·

I've literally never needed to do that. What's a real world use case?

3m 3y ago
Doing multiple async tasks concurrently as opposed to in sequence. If you have never used this you have either worked on extremely simple systems or have been leaving a ton of perf gains on the table.
- Capricorn2481 3y ago
  Or, like most people, they don't work with JS outside of the frontend where fetching multiple things in parallel is rarely needed.
- recursive 3y ago
  How is this different from await a, await b, await c?
  - jonathanlydall 3y ago
    If each await was to a setTimeout call waiting 1000ms, awaiting all 3 would take approximately 3000ms. If you await a Promise.all with an array of the promises, it will take approximately 1000ms. In summary, using individual awaits runs them serially, while Promise.all runs them concurrently. If you’re doing CPU bound work without workers, it doesn’t make much of a difference, but if you’re doing I/O bound tasks, like HTTP requests, then doing it in parallel will likely make a significant difference.
    - recursive 3y ago
      I get what you're saying, but that's just not how it works in my experience. I've got a repro in codepen. What am I missing? https://codepen.io/tomtheisen/pen/QWPOmjp https://codepen.io/tomtheisen/pen/QWPOmjp function delay(ms) { return new Promise(resolve => setTimeout(resolve, ms)); } async function test() { const start = new Date; const promises = Array(3).fill(null).map(() => delay(1000)); for (const p of promises) await p; const end = new Date; console.log("elapsed", end - start); // shows about 1010 } test();
      - jonathanlydall 3y ago
        What I imagined from your initial description is that you were doing the following: for (var i = 0; i < 3; i++) { await delay(1000); } However (as you are possibly well aware), this line in your example is starting all the work immediately and essentially in parallel: const promises = Array(3).fill(null).map(() => delay(1000)); So the timing of your for...of loop is that the first element probably takes about 1000ms to complete, and then the other two seem to happen instantly. Promise.all is just an alternative to writing the for...of await loop: await Promise.all(promises); I guess it relies on you already being familiar with the Promise API, but I feel that Promise.all() has slightly less cognitive load to read and its intent is more immediately clear. A strong case for preferring the Promise.all() is that Promise.allSettled(), Promise.any() and Promise.race() also exist for working with collections of promises, and unlike Promise.all(), they would not be so easily reproduced with a one liner for...of loop, so its not unreasonable to expect that JS developers should be aware of Promise.all(), meaning there is no reason for it not to be the preferred syntax for the reasons I stated above.
        recursive 3y ago
        Ok, I'm a believer. I misled myself into thinking there was more going on with Promise.all than there really was. I'm mildly averse to allocating unnecessary arrays. But this is mostly superstition rather than measurable performance concern. Promise.allSettled has a poor-mans implementation too. But the others really don't have such a thing. My impression is that Promise.all() is kind of nice, but it's really not that big a deal or important. If it didn't exist, you could get the same happy-path code behavior without really even changing the size of the calling code. But there's nothing wrong with it really. On balance, it seems slightly nicer than the poor-man's re-implementation. In the last 5 years, I might have been able to use it maybe twice.
      - MrJohz 3y ago
        You're starting all three promises, then waiting for the first one to finish, then waiting for the next one, then waiting for the last one. But because they were all started at the same time, they'll be run in parallel. Whereas if you started one promise, waited for it to finish, then started the next and so on, it would take the three seconds as they won't be run in parallel. The code you've written can be seen as a "poor-man's" Promise.all, in the sense that it's doing roughly the same thing but less clearly. It also behaves slightly differently in terms of rejections: if the final promise in the Promise.all version rejects immediately, then the whole promise will fail immediately. However, in your version, if the final promise rejects, that rejection won't be evaluated by the await (and therefore thrown) until all the other tasks have completed. For reasons of clarity and correctness, therefore, it's usually better to just use Promise.all rather than awaiting a list of already-started promises in sequence.
mattdesl 3y ago
I often map a series of X to Y with Promise.all. For example, mapping a series of image URIs to loaded Image elements. It is shorter to write than a for of loop, and importantly, all images will be loaded in parallel rather than sequentially, which can be significantly faster. images = Promise.all(uris.map(loadImage))
- recursive 3y ago
  You could also do it with a loop to start the promises and another one to await them. Is it just a shorter way of expressing that?
  - jonathanlydall 3y ago
    As per my other reply to you, there is a difference, a for loop will take the sum of each call to fetch the image while Promise.all will do the requests concurrently, meaning the total time will be that of the slowest request.
    - recursive 3y ago
      As per my other reply to your other reply, when I've written code that actually does `await` in a loop, it already does all the work concurrently. There's a code sample that illustrates what I'm familiar with. On the other hand, the language designers are not random framework authors. They know what they're doing. There must be some reason why `Promise.all` exists. I just don't know what it is. To re-iterate, I understand the difference between serial and parallel tasks. But I have also found that it's possible to do parallel tasks with `await` in a loop. So I'm still missing something.
      - mattdesl 3y ago
        To do parallel tasks in a loop for the situation I outlined (getting a final array of images from URIs), it would be really cumbersome, and your implementation would be pretty much equivalent to the inner workings of Promise.all. As others have mentioned; if you aren’t using Promise.all, you are likely missing a good deal of opportunities for easier and more performant async code.

3m 3y ago

Doing multiple async tasks concurrently as opposed to in sequence. If you have never used this you have either worked on extremely simple systems or have been leaving a ton of perf gains on the table.

Capricorn2481 3y ago
Or, like most people, they don't work with JS outside of the frontend where fetching multiple things in parallel is rarely needed.
recursive 3y ago
How is this different from await a, await b, await c?
- jonathanlydall 3y ago
  If each await was to a setTimeout call waiting 1000ms, awaiting all 3 would take approximately 3000ms. If you await a Promise.all with an array of the promises, it will take approximately 1000ms. In summary, using individual awaits runs them serially, while Promise.all runs them concurrently. If you’re doing CPU bound work without workers, it doesn’t make much of a difference, but if you’re doing I/O bound tasks, like HTTP requests, then doing it in parallel will likely make a significant difference.
  - recursive 3y ago
    I get what you're saying, but that's just not how it works in my experience. I've got a repro in codepen. What am I missing? https://codepen.io/tomtheisen/pen/QWPOmjp https://codepen.io/tomtheisen/pen/QWPOmjp function delay(ms) { return new Promise(resolve => setTimeout(resolve, ms)); } async function test() { const start = new Date; const promises = Array(3).fill(null).map(() => delay(1000)); for (const p of promises) await p; const end = new Date; console.log("elapsed", end - start); // shows about 1010 } test();
    - jonathanlydall 3y ago
      What I imagined from your initial description is that you were doing the following: for (var i = 0; i < 3; i++) { await delay(1000); } However (as you are possibly well aware), this line in your example is starting all the work immediately and essentially in parallel: const promises = Array(3).fill(null).map(() => delay(1000)); So the timing of your for...of loop is that the first element probably takes about 1000ms to complete, and then the other two seem to happen instantly. Promise.all is just an alternative to writing the for...of await loop: await Promise.all(promises); I guess it relies on you already being familiar with the Promise API, but I feel that Promise.all() has slightly less cognitive load to read and its intent is more immediately clear. A strong case for preferring the Promise.all() is that Promise.allSettled(), Promise.any() and Promise.race() also exist for working with collections of promises, and unlike Promise.all(), they would not be so easily reproduced with a one liner for...of loop, so its not unreasonable to expect that JS developers should be aware of Promise.all(), meaning there is no reason for it not to be the preferred syntax for the reasons I stated above.
      - recursive 3y ago
        Ok, I'm a believer. I misled myself into thinking there was more going on with Promise.all than there really was. I'm mildly averse to allocating unnecessary arrays. But this is mostly superstition rather than measurable performance concern. Promise.allSettled has a poor-mans implementation too. But the others really don't have such a thing. My impression is that Promise.all() is kind of nice, but it's really not that big a deal or important. If it didn't exist, you could get the same happy-path code behavior without really even changing the size of the calling code. But there's nothing wrong with it really. On balance, it seems slightly nicer than the poor-man's re-implementation. In the last 5 years, I might have been able to use it maybe twice.
    - MrJohz 3y ago
      You're starting all three promises, then waiting for the first one to finish, then waiting for the next one, then waiting for the last one. But because they were all started at the same time, they'll be run in parallel. Whereas if you started one promise, waited for it to finish, then started the next and so on, it would take the three seconds as they won't be run in parallel. The code you've written can be seen as a "poor-man's" Promise.all, in the sense that it's doing roughly the same thing but less clearly. It also behaves slightly differently in terms of rejections: if the final promise in the Promise.all version rejects immediately, then the whole promise will fail immediately. However, in your version, if the final promise rejects, that rejection won't be evaluated by the await (and therefore thrown) until all the other tasks have completed. For reasons of clarity and correctness, therefore, it's usually better to just use Promise.all rather than awaiting a list of already-started promises in sequence.

mattdesl 3y ago

I often map a series of X to Y with Promise.all. For example, mapping a series of image URIs to loaded Image elements. It is shorter to write than a for of loop, and importantly, all images will be loaded in parallel rather than sequentially, which can be significantly faster. images = Promise.all(uris.map(loadImage))

recursive 3y ago
You could also do it with a loop to start the promises and another one to await them. Is it just a shorter way of expressing that?
- jonathanlydall 3y ago
  As per my other reply to you, there is a difference, a for loop will take the sum of each call to fetch the image while Promise.all will do the requests concurrently, meaning the total time will be that of the slowest request.
  - recursive 3y ago
    As per my other reply to your other reply, when I've written code that actually does `await` in a loop, it already does all the work concurrently. There's a code sample that illustrates what I'm familiar with. On the other hand, the language designers are not random framework authors. They know what they're doing. There must be some reason why `Promise.all` exists. I just don't know what it is. To re-iterate, I understand the difference between serial and parallel tasks. But I have also found that it's possible to do parallel tasks with `await` in a loop. So I'm still missing something.
    - mattdesl 3y ago
      To do parallel tasks in a loop for the situation I outlined (getting a final array of images from URIs), it would be really cumbersome, and your implementation would be pretty much equivalent to the inner workings of Promise.all. As others have mentioned; if you aren’t using Promise.all, you are likely missing a good deal of opportunities for easier and more performant async code.