Skip to content

Promise performance drop between v8 7.4 and 7.5 #33384

Closed
Closed
Promise performance drop between v8 7.4 and 7.5#33384
Labels
performanceIssues and PRs related to the performance of Node.js.

Description

@Aschen
Aschen
opened on May 13, 2020

I was doing some benchmark about promises performances and I noticed a performance drop in traditional promises (then/catch) between Node.js 10 and Node.js 12.

With further investigation I'm now able to say that the performance drop occur between v8 7.4 (Node.js 12.0.0) and v8 7.5 (Node.js 12.5.0).

The performance drop is still present in recent version of v8 (tested with v8 8.1 on Node.js 14.2.0)

Promises are between 3x and 5x slower in v8 7.5 than in v8 7.4 and they are still 2x slower in v8 8.1

Do you have any idea why?

image

If we look at the bigger picture, we can see that promise performance were much more better at some point (Node.js 10) and then start to deteriorate

image

You can run the script present on this Gist to reproduce the benchmarks: https://github.com/proxy/gist.github.com/Aschen/1d35ccb6dc1dc3d6796b00cecfebb6d0

Activity

  1. mscdex commented on May 13, 2020

    @mscdex
    mscdex
    on May 13, 2020
    Contributor

    Out of curiosity, did you try the master branch, which now has V8 8.3?

  2. targos commented on May 13, 2020

    @targos
    targos
    on May 13, 2020
    Member

    The following download has V8 8.3 if you want to test it: https://nodejs.org/download/nightly/v15.0.0-nightly202005135bb4d01fbe/

  3. Aschen commented on May 14, 2020

    @Aschen
    Aschen
    on May 14, 2020
    Author

    @mscdex I updated the benchmark and the script to use the version @targos linked and the results are worse with the latest version of Node.js / v8

  4. Aschen commented on May 21, 2020

    @Aschen
    Aschen
    on May 21, 2020
    Author

    This issue is being addressed here https://bugs.chromium.org/p/v8/issues/detail?id=10550

  5. camillobruni commented on Jul 9, 2020

    @camillobruni
    camillobruni
    on Jul 9, 2020
    Contributor

    After some investigation I found the root cause: V8 changed the default page size from 512 KiB (v7.4) to 256 KiB (v7.5)

    Some background:

    • performance.js measures with process.memoryUsage()
    • Memory usage in V8 is calculated by iterating over all Pages
    • The number of pages doubled in v12.5 since V8 v7.5 reduced the default page size

    Take-away:

    • bluebird should probably not time the memory measurements (presuming this is not something that is happening very often)
    • Node should provide a fast API for just accessing RSS itself (rss is cheap, heap-stats are more expensive)

  6. camillobruni commented on Jul 9, 2020

    @camillobruni
    camillobruni
    on Jul 9, 2020
    Contributor

    FYI, to underly my comment about measuring the right thing:
    Commenting out the memMax = Math.max(memMax, process.memoryUsage().rss); line in performance.js makes the benchmark run 3x faster in node v12.5.

  7. Aschen commented on Jul 10, 2020

    @Aschen
    Aschen
    on Jul 10, 2020
    Author

    Thanks you very much @camillobruni for all these explanations!

    I submitted a PR in Bluebird to fix those benchmarks and another one in Node.js to add a direct access to the rss.

    Also updated the original article at https://blog.kuzzle.io/bluebird-native-async_await-javascript-promises-performances-2020

  8. Leodau commented on Jul 10, 2020

    @Leodau
    Leodau
    on Jul 10, 2020

    @ryzokuken

  9. benjamingr commented on Jul 10, 2020

    @benjamingr
    benjamingr
    on Jul 10, 2020
    Member

    Hey, I totally missed this issue - cool investigation I'll take a look at the bluebird issue.

    Note that:

    • V8 has their own forked version of the bluebird benchmark (which I think @bmerurer made?), IMO it's slightly worse (because it doesn't measure the overhead of promisification) but it's probably more maintained.
      • These benchmarks haven't been updated on the bluebird side in ~5 years and were written for CrankShaft (the old JIT), it (and bluebird) make a lot of (now incorrect) assumptions regarding how the benchmarks are run and I would not want people to use them as an authoritative source. It's kind of shameful Doxbee is still the best we have for this in non-micro-benchmark land.
      • I'm also a Node member - and there are lots of promise performance and debugging tasks Node needs helps with :]
      • If you want to add a promise performance benchmark to Node core that we run to detect regressions that could be a good place to contribute - though not where I'd start.
    • We've been trying to get people to use native promises (and improve those!) where possible.
    • Promises are generally "fast enough" for most use cases afaict.

  10. mmarchini commented on Jul 30, 2020

    @mmarchini
    mmarchini
    on Jul 30, 2020
    Contributor

    @benjamingr I believe you're referring to these benchmarks?

  11. targos
    added
    performanceIssues and PRs related to the performance of Node.js.
    on Dec 27, 2020
  12. nodejs-github-bot
    added a commit that references this issue on Jan 3, 2021

    process: add direct access to rss without iterating pages

    83ab543

  13. Aschen commented on Jan 10, 2021

    @Aschen
    Aschen
    on Jan 10, 2021
    Author

    The cause of the issue has been identified: the process.memoryUsage().rss iterate on every pages and the size of allocated pages has been divided by to between v8 7.4 and 7.5 so iterating over the pages to compute memory usage statistics is much more longer.

    A new fast access to the rss has been implemented and will land on the next Node.js release: process.memoryUsage.rss()

  14. Aschen
    closed this as completedon Jan 10, 2021
  15. danielleadams
    added a commit that references this issue on Jan 12, 2021

    process: add direct access to rss without iterating pages

    92af503
  16. targos
    added a commit that references this issue on Aug 8, 2021

    process: add direct access to rss without iterating pages

    e46b2e5
  17. BethGriggs
    added a commit that references this issue on Aug 12, 2021

    process: add direct access to rss without iterating pages

    9aeb9b1
  18. MylesBorins
    added a commit that references this issue on Aug 31, 2021

    process: add direct access to rss without iterating pages

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    performanceIssues and PRs related to the performance of Node.js.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions