Uh oh!
There was an error while loading. Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork 34.4k
os: improve cpus() performance#11564
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
Uh oh!
There was an error while loading. Please reload this page.
Conversation
mscdex commented Feb 26, 2017 • edited
Loading Uh oh!
There was an error while loading. Please reload this page.
edited
Uh oh!
There was an error while loading. Please reload this page.
bnoordhuis left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM with a suggestion.
src/node_os.cc Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another possible enhancement: cache the result and check on the next iteration:
Local<String> model_string; int model_index; // Then inside the loop...if (model_string.IsEmpty() || 0 != strcmp(ci->model, cpu_infos[model_index).model){model_string = OneByteString(env->isolate(), ci->model); model_index = i} Local<Value> argv[] ={model_string };There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just tried that in addition to the changes I just made and did not see any difference.
mscdex commented Feb 26, 2017 • edited
Loading Uh oh!
There was an error while loading. Please reload this page.
edited
Uh oh!
There was an error while loading. Please reload this page.
I've now tweaked the code to squeeze out a bit more speed. |
JacksonTian commented Feb 27, 2017
LGTM |
src/node_util.cc Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume the old PropertyAttribute-based API is used rather than the ES5 PropertyDescriptor-based one for ease of backporting?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just copied from the READONLY_PROPERTY macro in src/node.cc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could leave out the ReadOnly flag entirely since it's only a bindings object property.
src/node_util.cc Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could leave out the ReadOnly flag entirely since it's only a bindings object property.
gibfahn commented Feb 27, 2017 • edited
Loading Uh oh!
There was an error while loading. Please reload this page.
edited
Uh oh!
There was an error while loading. Please reload this page.
@mscdex looks like every test failed on AIX (there were also SmartOS failures, but I'm not sure what caused them). I suspect this was caused by the |
mscdex commented Feb 28, 2017 • edited
Loading Uh oh!
There was an error while loading. Please reload this page.
edited
Uh oh!
There was an error while loading. Please reload this page.
Alright, after duplicating the issue on a smartos16-64 CI node (base-64 16.2.0), the crash appears to be happening in V8, not in node's code. I did a The example test I used to trigger this was test/parallel/test-async-wrap-check-providers.js. /cc @nodejs/v8 ? |
bnoordhuis commented Feb 28, 2017
Does it also crash with cc @nodejs/platform-smartos because it happens in libumem. |
mscdex commented Feb 28, 2017
@bnoordhuis With that flag it still crashes. This time the backtrace is: |
mscdex commented Mar 2, 2017 • edited
Loading Uh oh!
There was an error while loading. Please reload this page.
edited
Uh oh!
There was an error while loading. Please reload this page.
False alarm, it was just a bug in the code I added. It only appeared on the SmartOS and AIX CI machines because they had a large enough CPU count to trigger the bug. New CI: https://ci.nodejs.org/job/node-test-pull-request/6653/ |
bnoordhuis left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM with a suggestion.
src/node_os.cc Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Call this field_idx maybe?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed.
mscdex commented Mar 2, 2017
CI is green except for unrelated test failures. Hooray! |
gibfahn commented Mar 2, 2017
Rerun of CI was even more green! |
PR-URL: nodejs#11564 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Jackson Tian <[email protected]>
PR-URL: #11564 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Jackson Tian <[email protected]>
MylesBorins commented Apr 17, 2017
@mscdex thoughts on backport? |
Results with included benchmark:
CI: https://ci.nodejs.org/job/node-test-pull-request/6591/
Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passesAffected core subsystem(s)