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

Bluebird 3.x performance in webpack #897

Closed
suprememoocow opened this issue Dec 1, 2015 · 6 comments
Closed

Bluebird 3.x performance in webpack #897

suprememoocow opened this issue Dec 1, 2015 · 6 comments

Comments

@suprememoocow
Copy link

@suprememoocow suprememoocow commented Dec 1, 2015

This issue seems totally bizarre to me. I'm not sure whether to file it under webpack or Bluebird, but since it may be affecting other bluebird users I'll file it here.

I've been finding that Bluebird's performance in the browser has been pretty shoddy since I upgraded to bluebird 3.

In an effort to diagnose the problem, I started conducting some tests here: https://github.com/suprememoocow/bluebird-webpack-perf

The results are strange to say the least, but here's some of what I'm seeing:

      module: {
        noParse: [
          /bluebird\/js\/browser\/bluebird\.js/
        ]
      },
      node: {
        console: false,
        global: false,
        process: false,
        Buffer: false,
        __filename: false,
        __dirname: false,
        setImmediate: false
      },
  • Changing these settings hasn't helped.
  • Downgrading to Bluebird 2.x.x fixes the problem.

I'll conduct some further tests and see if I can get to the bottom of the problem

@suprememoocow
Copy link
Author

@suprememoocow suprememoocow commented Dec 1, 2015

More strange results:

  • The problem does not occur in Firefox 42.0 or Safari 9.0.1 on OSX.
  • It does occur in Chrome 47.0.2526.73 beta (64-bit) and Chrome Canary Version 49.0.2578.0 canary (64-bit)

@suprememoocow
Copy link
Author

@suprememoocow suprememoocow commented Dec 1, 2015

Doing some profiling I noticed that bluebird is capturing long stack traces even though I have

Promise.config({
    warnings: false,
    longStackTraces: false, // <-- Turn off long stack traces
    cancellation: true
  });

This would explain why Chrome is getting the performance hit, but not Firefox or Safari.

Upon further investigation, it looks like the __DEBUG__ constant is being set to true for the build of js/browser/bluebird.js if you compare:

js/browser/bluebird.js:658:var debugging =!!(true || util.env("BLUEBIRD_DEBUG") ||

to the original source, here: https://github.com/petkaantonov/bluebird/blob/master/src/debuggability.js#L18

@benjamingr
Copy link
Collaborator

@benjamingr benjamingr commented Dec 1, 2015

I'm sorry - but what scenario do you have in client side code when you'd rather have performance over long stack traces?

@suprememoocow
Copy link
Author

@suprememoocow suprememoocow commented Dec 1, 2015

@benjamingr when running in production.

The minified version of the browser build has __DEBUG__ set to false and that's why it doesn't suffer from the same performance problem. When you're using Webpack or Browserify with npm however, you use the non-minified version, so __DEBUG__ is set to true.

Obviously, I can still set longStackTraces to true using Promise.config, but that's my prerogative as an Bluebird user and I'll enable it when running in development mode. As things stand, Promise.config({ longStackTraces: false }) has no effect when using Bluebird via Webpack - it's always true whether you want it to be or not.

The reason I started investigating this bug is that I'm writing a bluebird based Bayeux client for Gitter.im. I noticed that compared to the old Bayeux client, it was noticeably and quite obviously slower (for example, when switching rooms on Gitter). On investigation, this seems to be the problem.

As a practical example of how this affects performance, I was previously using Promise.reduce to pass incoming and outgoing messages through a set of extensions. For a small number of extensions, this was adding more than 500ms to the time it took for a message to pass through the client onto the transport. I worked around this issue by removing Promise.reduce but this hack wouldn't be required if bluebird was running at full-speed.

In the example repo above, having this turned on slows things down by about ~250 times in Chrome.

Bluebird is all about performance and it's crazy fast, so why not let application developers choose when to hobble it with long stack traces?

a

@petkaantonov
Copy link
Owner

@petkaantonov petkaantonov commented Dec 1, 2015

with browserify and webpack youre supposed to use the npm module

the downloaded file is for script tag users

@suprememoocow
Copy link
Author

@suprememoocow suprememoocow commented Dec 1, 2015

@petkaantonov, I am using the npm module, which references js/browser/browser.js, which is currently built with __DEBUG__ set to true. #898 is my attempt at changing this.

References:
require('bluebird')
package.json

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants