Re: [whatwg] Proposal: createImageBitmap should return a "Promise" instead of using a callback

On 07/17/2013 07:51 PM, Tab Atkins Jr. wrote:
> On Jul 17, 2013 8:40 PM, "Ruben Rodriguez II" <whatwg@therealcha0s.net>
> 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

Received on Thursday, 18 July 2013 01:00:38 UTC