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.
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.
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();
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.
In order to use `Promise.all`, you'd still have to construct all the promises without awaiting them. That seems like the whole foot-gun and cognitive load right there.
But the early rejection is a concrete improvement over the "poor-man's" version. I'm sold.
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.
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.
I think you are confusing the speed at which the earth orbits the sun (~29.8km/s) with the speed at which an object needs to travel to maintain earth orbit (~7.8km/s).
Whoops, you are right. I think it's too late to edit my original post.
The point still stands, though, you have to get to nearly 8km/s otherwise you aren't in orbit and you fall back into the atmosphere.
You can't get to anywhere near that speed while still in the atmosphere - SR-71s only manage about 1km/s, and because kinetic energy is proportional to the square of the speed, at that point you are only 1/64th of the way there.
Umm isn't that the point of trying to reverse aging ..to look normally youthful not look so unusual that the look isn't youthful at all just unusual. Look at all the comments here that agree some saying the look is that of a vampire. Thats what the majority thinks and wishes for when it comes to reverse aging ..to be and look 20 again yet with all the wisdom and wealth gained over the years.
Just to keep the sarcasm going: Is there a scientific test that checks for "looking like a vampire"?. Cause he sure does to me, but I'm not a vampire-specialist, so what do I know...
This is beyond the Juicero level of startup nonsense.
Watching the video of Gerry Tan and the founder describing the design as “space warping” was tedious.
In this thread: lots of people who have never started a business giving advice to a guy who was making 600k/mo about why his business was dumb. Hacker News at its best.
reply