On 07/17/2013 07:51 PM, Tab Atkins Jr. wrote:
On Jul 17, 2013 8:40 PM, "Ruben Rodriguez II" <[email protected]>
wrote:
This is exactly what I was thinking when I was reading this. I have been
building a game engine with async JS and I have run into situations where
promises were absolutely sapping performance.
I would encourage people to look over even the faster promise libraries
and understand just how much complexity they introduce, and how many 'next
tick'-type operations that a cascading promise chain can stimulate.
It's wonderful because of how entirely promises cover your execution
path, making control flow silky smooth and safe. However it does come at a
price, and any API at a 'system' level should strive to implement features
in the most performant way by default: a callback. It'll take 1 day to wrap
your API with a promise-based API for people who would make that tradeoff.
If you sacrifice speed first, there's no way to go back the other way.
Forcing people to wrap with their own code is just a way of saying "lol,
we're not actually doing that".
There's Q's deferred.makeNodeResolver()...
Callbacks are no faster than promises,
This isn't starting well...
because to maintain consistent
semantics, they have to delay across ticks anyway.
It's not about 'delaying across ticks', it's about how many extra tick
delays resolving a composed promise chain is causing. Every time you do
promise.then(resolver), you're (invisibly) creating yet another promise,
in yet another tick. These things add up, again I would encourage you to
study some promise libraries. We can't credibly ascribe a zero cost to
promises.
Homebrew callback
systems can ignore that, but only because they're not as worried about
overall API correctness, and are okay with making their users deal with
sometimes-synchronous code.
~TJ
