Bluebird is mainly designed for node (V8) and promise performance can make a massive difference on the server. On the client there tend to be fewer async calls and so promise performance is usually less of a factor, but obviously, it depends what you're doing.
If it takes 100ms CPU time to process 10 promises and 1 request involves creating 10 promises, the server can then only handle 100 requests per second at theoretical max.
IO time doesn't matter as much (for throughput) because IO is asynchronous so the server is free to process other requests while waiting for it. But CPU time is only being used for 1 thing at at time.
So to get e.g. 10k rps out of a node server, handling 100000 promises must take well under a second of CPU time. Looking at the benchmark results you can see how many implementations will bottleneck this.
Check out the Bluebird benchmarks [0], or you can easily try it for yourself - create a simple web server which does some makework async task, like stating a bunch of files, then benchmark with ab or something better.
You haven't provided any evidence so far. You owe evidence because you made a claim. If you are unsure whether Bluebird's Promise performance makes a difference in a real-world scenario, why make such a claim?
You are asking a question, I do not owe you an answer, it's up to you to find out whether this stuff matters for your use case. I've done these tests myself, it is trivial for you to do the same. Do your own homework.
> You are asking a question, I do not owe you an answer
I agree! But you did answer it:
> Bluebird is mainly designed for node (V8) and promise performance can make a massive difference on the server.
If I'm sacrificing simplicity (by using a non-native Promise implementation with a very large API) because of performance improvements, I want data (proof) of these performance improvements. If you don't have the data that's fine! No harm done, I'll keep waiting until someone does.
> Isn't the whole point of promises that they can be chained together without nesting?
Yes, it's an excedingly common misunderstanding and probably one of the main causes of people being "turned off" by promises. It's kind of frustrating to see so many blog posts making this mistake when critiquing them.
And there's just about never a reason to use the `Promise` constructor in real world code. If you already have a promise as in your example, so you can rewrite your refactoring as:
> And there's just about never a reason to use the `Promise` constructor in real world code
Why not? If I want to wrap a callback function in a promised sequence, I don't see a way around it. Please don't suggest importing bluebird/promisifyAll because that only teaches me how to avoid thinking about the problem, not how it's actually solved, let alone why it's a problem to begin with.
function promiseMeFoo() {
return new Promise((resolve, reject) => {
asynchronousFoo((err, out) => {
if (err) return reject(err);
return resolve(out)
});
});
}
^ aside from just rearranging the code for legibility, how can I do the same thing without constructing a promise explicitly?
Bluebird's `promisifyAll()` is just a way to generalize that pattern, so that you don't need to write it yourself. And if you care about performance it's substantially faster too. If you want to learn about the pattern then fine, but personally I don't want to write that for every single `fs` function I use in a project, it's much more convenient to just `Bluebird.promisifyAll(require('fs'))`.
I noticed this as well. On the other hand, even though the example the author provided could be substantially simplified as you showed, if you wanted to later on refactor the `getUsers` function again to add more logic, your promises code would end up more and more contorted. In practice I've found `await` and `async` to hugely simplify these kinds of complex promises.
I have the opposite experience of that. Generally function-based promise code is just about the same as async/await. It does take some time to get used to all the equivalencies between imperative code and promises though.
AKA the explicit construction anti-pattern: stackoverflow.com/questions/23803743/what-is-the-explicit-promise-construction-antipattern-and-how-do-i-avoid-it/23803744
This is happening because of compiler optimisation technique called Loop Invariant Code Motion [0], which means that the author is not measuring what he thinks he's measuring (and this should be obvious from the numbers really), so the result is meaningless.
Replying to myself because it is too late to edit: thinscript isn't exactly typescript, it has some extra features and doesn't attempt full js compatibility, but they are very similar.
Here's a typed objects system for JS which uses ArrayBuffers for backing storage, in future it will also support SharedArrayBuffer - https://github.com/codemix/reign (disclaimer: I wrote this).
Falcon Heavy is late, but making Falcon Heavy economical means making all of the 3 F9 first stages it uses reusable. They haven't cracked that yet, they've got 2 good landings and a lot of data, but it's far from certain whether e.g. the landing attempt next week will be successful.
Most of their customers do not need the extra payload / push of Falcon Heavy and so they're concentrating on making F9 itself work first. This is reasonable I think.
I'm right there with you on SpaceX and timelines (my recent post history here includes trying to convince folks that just because they landed a stage doesn't mean cheap and easy rocket reuse is right around the corner). In this case however, my gut feeling is that they're a lot deeper into the development cycle of this project and they feel pretty confident about the 2018 timeframe.
The implication is that driving over the speed limit is likely, on average, to be less fuel efficient than obeying it. Due to the laws of human nature, very few people drive significantly below the speed limit, and very few people prioritise their fuel economy over everything else so this translates to a reasonable guideline.
The implication is that driving over the speed limit is likely, on average, to be less fuel efficient than obeying it.
Not necessarily, because of gear changes. Not all cars can use 5th gear in a 50km/h zone, so they'll drive in 4th gear. It seems likely that doing 60km/h in 5th gear is more efficient than 50km/h in 4th gear.
