Adding caching for this._isFulfilled(). On an app I tested it in, the av...

[marchant]

...erage time for Promise._settlePromiseAt() was 12ms, with that change, going down to 7ms, and total, going down from 900ms to 760ms, so about 18% performance increase

[marchant]

All test passed with node tools/test

[petkaantonov]

First about the scheduler, MessageChannel is unacceptable because it is bugged in some browsers. If this is ok for your application then you can use Promise.setScheduler but it cannot be used in the general case.

I cannot see any difference from the isFulfilled caching alone, testing in node 0.12

[marchant]

Promise.setScheduler, excellent, works like a charm, well done. I’m focusing tests on client, and especially mobile, it matters there. If there’s no difference on node than sounds like a win to me.

On Feb 20, 2015, at 12:01 AM, Petka Antonov notifications@github.com wrote:

First about the scheduler, MessageChannel is unacceptable because it is bugged in some browsers. If this is ok for your application then you can use Promise.setScheduler but it cannot be used in the general case.

I cannot see any difference from the isFulfilled caching alone, testing in node 0.12

—
Reply to this email directly or view it on GitHub #505 (comment).

[petkaantonov]

I don't have a mobile to test but if we are gonna do this we can do much better. We can load the bitfield once and use a macros like IS_FULFILLED(bitField) which compiles to e.g. ((bitField & 21319204) !== 0) so that testing all flags is fast and don't require a method call and a memory load.

[marchant]

That sounds great!

On Feb 20, 2015, at 12:13 AM, Petka Antonov notifications@github.com wrote:

I don't have a mobile to test but if we are gonna do this we can do much better. We can load the bitfield once and use a macros like IS_FULFILLED(bitField) which compiles to e.g. `((bitField & 21319204) !== 0) so that testing all flags is fast and don't require a method call and a memory load.

—
Reply to this email directly or view it on GitHub #505 (comment).

[benjamingr]

@marchant you should develop against 3.0 (the coming release) and not against master fwiw.

[marchant]

Ok, thanks, I'll have to figure out how to do the browser build then!

On Feb 23, 2015, at 10:43, Benjamin Gruenbaum notifications@github.com wrote:

@marchant you should develop against 3.0 (the coming release) and not against master fwiw.

—
Reply to this email directly or view it on GitHub.

[petkaantonov]

node tools/build --browser

[marchant]

Thanks, appreciated!

On Feb 23, 2015, at 11:48, Petka Antonov notifications@github.com wrote:

node tools/build --browser

—
Reply to this email directly or view it on GitHub.

[marchant]

What is 3.0 bringing?

On Feb 23, 2015, at 10:43, Benjamin Gruenbaum notifications@github.com wrote:

@marchant you should develop against 3.0 (the coming release) and not against master fwiw.

—
Reply to this email directly or view it on GitHub.

[petkaantonov]

@marchant

• Website with better documentation, guides, tutorials, how-tos etc..
• New cancellation and all the issues which are labeled 3.0 in github
• A minor backward incompatible with Promise.delay, which puts the optional value argument as last instead of first
• Fair perf increase, especially for the parallel benchmark which now in 3.0 actually performs faster than the sequential one!

[benjamingr]

@marchant also:

• Better debugging experience with warnings that let you know about many common pitfalls (like a lint)
• Cleaning the API.
• Promises got a lot lighter (allocating them now is dirty cheap, cheaper than allocating an empty array)

[petkaantonov]

Outdated example of warnings: http://imgur.com/a/t3xng (constructor return is removed now and several new ones are added that are not in the album)