Use an alternative to Bluebird in forked threads.

[jamestalmage]

With #390 - bluebird is now %37 of our load time according to time-require. It takes about 50ms on my machine (w/ fast SSD's).

pinkie takes <= 1ms to load on the same machine.

It seems like we mostly use the bluebird bells and whistles in the main thread. When it comes to forks, I think our only use of a bluebird specific API is here.

I wrote this simple benchmark (It is really naive, I know):

var start = new Date().getTime();

var Promise = require('pinkie');
// var Promise = require('bluebird');

var count = 0;
function next() {
  var end = new Date().getTime();
  if (end - start > 80) { // adjust this up and down
    console.log(count);
    return
  }
  count ++;
  Promise.all([1, 2, Promise.resolve(3), Promise.resolve(4)]).then(next);
}

next();

On my machine the break even point is 80 ms, at which point both implementations have completed just about 6,000 cycles of the above loop. We now create at least one promise for each assertion, and a couple per test. Still, it is hard to imagine any reasonable test file generating the 6,000+ promises necessary to break even using bluebird.

[ariporad]

Hmm... Seems like a great idea. And we don't even have to load anything if there's already a native promise.

Want me to have a go at implementing this?

[jamestalmage]

we don't even have to load anything if there's already a native promise

Yep, use pinkie-promise for that.

Want me to have a go at implementing this?

Lets get consensus with the plan first.

[jamestalmage]

Long stack traces might be a good reason to keep Bluebird around.

See #394.

[alubbe]

Just to chime in from the sidelines, I see two quick points in favor of keeping it:

1. Long stack traces are a really beautiful feature, and much less expensive with bluebird than with most alternatives
2. My main helper file requires (my own version of) bluebird (which is the same as ava's), so if ava switches to another implementation, it will actually make it slightly slower for me.

Granted, point 2 doesn't hold for everyone and at some point in time there may be a mismatch between my version of bluebird and ava's. But it's not uncommon and something to keep in mind.

[sindresorhus]

I don't think it's worth dropping Bluebird. Long stack traces are very useful, especially when it comes to testing.

50ms is a long time for just require & parsing though. Might be worth looking more closely into why it takes so long. Maybe there's something we could do to improve it or at least open an issue on the Bluebird issue tracker about it.

[jamestalmage]

Nothing jumps out: https://gist.github.com/jamestalmage/873252568d8487bb1d95

[sindresorhus]

82 bluebird (node_modules.../release/bluebird.js) 45ms ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇ 85%

I was thinking using https://github.com/s-a/iron-node flame graphs to see what actually slows down the loading. Maybe something in Bluebird could be made lazy.

[jamestalmage]

Yes, but if you create this:

// index.js
require('time-require');
require('./foo.js');

// foo.js
require('bluebird');

you get this:

32 bluebird (node_modules.../release/bluebird.js) 48ms ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇ 84%
33 ./foo (foo.js) 48ms ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇ 84%

The output is cumulative of the require time for everything you require, plus your time to eval and return. While bluebird itself takes a long time, everything it requires is really fast (<1ms)

[jamestalmage]

I was thinking using https://github.com/s-a/iron-node flame graphs

I just tried that, I am not finding it super useful either.

Maybe something in Bluebird could be made lazy.

My only thought would be "make everything lazy".

[novemberborn]

How does #394 help with long stack traces? Presumably this only helps us if there is a crash in the test worker? Is it meant to help debug crashes in before/after hooks?

Other than that it helpfully enables long stack traces for users who also rely on bluebird, but that seems more like an undocumented side-effect.

If the stack traces are useful for end-users then we should close this issue IMO.