Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Something wrong with the implementation of the "promise.then" #3414

Closed
Daeren opened this issue Oct 17, 2015 · 3 comments · May be fixed by sirinartk/node#7, adamlaska/node#28, adamlaska/node#29, kissofire/node#11 or adamlaska/node#31
Labels
memory Issues and PRs related to the memory management or memory footprint. v8 engine Issues and PRs related to the V8 dependency.

Comments

@Daeren
Copy link

Daeren commented Oct 17, 2015

Win 7 x64 | Node.js v4.2.1

Code:

var t = 1000 * 1000 * 1;

function fCookie(x, z) {
    return new Promise(resolve => resolve(x + z));
}

console.time("#1 | Promise");
while(t--) fCookie(1, 3).then(function(r) {});
console.timeEnd("#1 | Promise");

Results:

//-] Without: ".then"
//>  1m - 400ms - 20Mb RAM (nodejs Promise)
//>  1m - 300ms - 15Mb RAM (bluebird Promise)

//-] With: ".then"
//>  1m - 4899ms - 1.1Gb RAM (nodejs Promise) ~ (4x | 3x)
//>  1m - 1255ms - 370Mb RAM (bluebird Promise)

So a lot of memory, so slow ...

@thefourtheye
Copy link
Contributor

Most likely a v8 thing, as Node.js uses underlying v8's Promise implementation.

@mscdex mscdex added the v8 engine Issues and PRs related to the V8 dependency. label Oct 17, 2015
@benjamingr
Copy link
Member

Yes, native promises are slower and consume more memory than bluebird promises, this is a well known fact. I think the issue can be closed.

@Trott
Copy link
Member

Trott commented Oct 18, 2015

According to this from the v8 mailing list:

This is a known problem. Several reasons:

  1. V8 promises haven't been optimised at all. It's on our agenda once our ES6 support is feature complete.
  2. V8 promises support various callback hooks into devtools, which cause a certain overhead.
  3. Alternative promise implementations tend to take shortcuts relative to the official ES6 semantics (e.g., goog.Promise.all you use below does not support subclassing correctly).

We assume that (1) is the main factor, and will go away eventually, but due to the others some (hopefully minor) differences might remain.

If you have further questions/concerns, I would recommend participating over there. (Promises aren't in Node core. They're supplied by v8.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment