Repository navigation
Closed
Labels
performanceIssues and PRs related to the performance of Node.js.Issues and PRs related to the performance of Node.js.questionIssues asking questions about Node.js.Issues asking questions about Node.js.
Description
Occurs on both OSX and Linux (Travis CI).
- Version: 8.0.0
- Platform:
- Darwin Miless-MBP 16.5.0 Darwin Kernel Version 16.5.0: Fri Mar 3 16:52:33 PST 2017; root:xnu-3789.51.2~3/RELEASE_X86_64 x86_64
- "linux", version: "3.13.0-29-generic", arch: "amd64", family: "unix"
- Subsystem:
I've noticed that one of my projects unit tests are running 4-5x slower on Node v8 than previous versions. I have yet to determine the cause, but an example can be found in the Travis builds: https://travis-ci.org/milesj/emoji-database
This is 100% reproducible and consistent, even on OSX. Here's an output of the tests being run on OSX (notice the times).
$ NODE_ENV=test run-tests
PASS tests/extractGender.test.js
PASS tests/cleanName.test.js
PASS tests/extractSkinTone.test.js
PASS tests/createShortnames.test.js
PASS tests/createTags.test.js
PASS tests/extractSet.test.js
PASS tests/fromUnicodeToHex.test.js
PASS tests/fromHexToCodepoint.test.js
PASS tests/regex.test.js (57.436s)
PASS tests/packageData.test.js (121.958s)
Test Suites: 10 passed, 10 total
Tests: 51415 passed, 51415 total
Snapshots: 0 total
Time: 123.471s, estimated 129s
Ran all test suites.
Compared to Node v7.
$ NODE_ENV=test run-tests
PASS tests/extractSet.test.js
PASS tests/extractGender.test.js
PASS tests/createTags.test.js
PASS tests/extractSkinTone.test.js
PASS tests/cleanName.test.js
PASS tests/createShortnames.test.js
PASS tests/fromUnicodeToHex.test.js
PASS tests/fromHexToCodepoint.test.js
PASS tests/regex.test.js (8.174s)
PASS tests/packageData.test.js (11.178s)
Test Suites: 10 passed, 10 total
Tests: 51415 passed, 51415 total
Snapshots: 0 total
Time: 13.606s
Ran all test suites.
Metadata
Metadata
Assignees
Labels
performanceIssues and PRs related to the performance of Node.js.Issues and PRs related to the performance of Node.js.questionIssues asking questions about Node.js.Issues asking questions about Node.js.
Activity
mscdex commentedon Jun 4, 2017
I was about to try to look into it myself, but it appears the
emoji-databasemodule depends on at least a 148mb dependency (emojione) that npm wants nothing to do with.Have you tried running with the appropriate V8 flags to see if things are being deoptimized permanently or something similar? You can check for permanent deopts with:
Otherwise you can generally see what V8 is optimizing, deoptimizing, and/or inlining or not with the
--trace-opt,--trace-deopt, and--trace-inliningflags respectively.milesj commentedon Jun 4, 2017
Here's the output of the first command.
I'll mess around with the others.
mscdex commentedon Jun 4, 2017
Try fixing those permanent deopts first and see what kind of impact that has. For example, the ones about
letorconstwould involve changing variable declarations in those functions one by one back tovaruntil the deopt message disappears.The others like 'Bad value context for arguments value' may not be as straightforward. That particular deopt typically has to do with having
func.apply(..., arguments)in functions that have properties tacked onto them. It's hard to say whether this is being done in the test runner itself, just in the tests, or in the actual module code.vsemozhetbyt commentedon Jun 4, 2017
You can also check if your code heavily uses the patterns that are currently slower in the Node.js 8 in comparison with the previous versions:
https://fhinkel.github.io/six-speed/
cc @nodejs/performance, @nodejs/v8
bmeurer commentedon Jun 4, 2017
Can you try with
--turboor alternatively using Node LKGR?ctdio commentedon Jun 6, 2017
I too have been seeing some slower performance on node 8.0.0 with one of my projects. In my case, I managed to narrow down the culprit and found that
String.prototype.splitis approximately 5x slower now. I haven't tried benchmarking any of the other string methods to see if there were performance hits there.@milesj I peeked into your code and saw that one of your tests uses
splitquite frequently. I have a strong feeling that you are seeing the same performance issues I am.vsemozhetbyt commentedon Jun 6, 2017
@charlieduong94 I cannot reproduce the
String.prototype.splitslowdown with a naive test:Code and results (click me):
mscdex commentedon Jun 6, 2017
@charlieduong94 Can you share the snippet of code you used to benchmark that function? Also, which other node version did you compare with (besides node v8.0.0)?
ctdio commentedon Jun 6, 2017
Here's the snippet. I used benchmark.js to run the function as many times as possible in quick succession. I compared against node 7.6.0.
Here are the results I got:

mscdex commentedon Jun 6, 2017
I think I've verified this. Here's a simpler reproduction:
Results:
milesj commentedon Jun 6, 2017
Thanks guys for looking into this. I've been out of town the last few days and am just now getting back to this.
I've ran both
--trace-deoptand--trace-inlining, but I'm not exactly sure what I should be looking for. Here's the output.Details
The deopt output is far too large, but it was basically repeating this a lot.
Details
bmeurer commentedon Jun 6, 2017
@schuay can probably shed some light on this.
17 remaining items
deps: cherry-pick 866ee63 from upstream V8
deps: cherry-pick 866ee63 from upstream V8
deps: cherry-pick 866ee63 from upstream V8
deps: cherry-pick 866ee63 from upstream V8
deps: cherry-pick 866ee63 from upstream V8
deps: cherry-pick 866ee63 from upstream V8
deps: cherry-pick 866ee63 from upstream V8
deps: cherry-pick 866ee63 from upstream V8