Uh oh!
There was an error while loading. Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork 34.3k
benchmark: replace [].join() with ''.repeat()#12170
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
vsemozhetbyt commented Apr 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.
vsemozhetbyt commented Apr 2, 2017
benchmark/es/string-repeat.js 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.
Why [...str].length instead of just str.length?
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.
It is unicode-proof, it counts code points, not char codes:
> '\ud83d\udc0e'.repeat(10).length 20 > [...'\ud83d\udc0e'.repeat(10)].length 10 benchmark/es/string-repeat.js 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 like this style but I think it's not widely used in the codebase.
Is it better to put the for body in the next line?
Also is it ok to use let in for loops like this now?
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 will wrap to conform.
It seems let in loops is mostly optimized now. At least they are rather common in tests or benchmarks.
Also add a benchmark to compare both ways to create strings.
vsemozhetbyt commented Apr 3, 2017
New linter CI: https://ci.nodejs.org/job/node-test-linter/7990/ |
Also add a benchmark to compare both ways to create strings. PR-URL: #12170 Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: James M Snell <[email protected]>
jasnell commented Apr 4, 2017
Landed in 74dc3bf |
Also add a benchmark to compare both ways to create strings. PR-URL: nodejs#12170 Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: James M Snell <[email protected]>
MylesBorins commented Apr 18, 2017
lts? |
Refs: #12170 PR-URL: #12317 Reviewed-By: James M Snell <[email protected]>
Refs: #12170 PR-URL: #12317 Reviewed-By: James M Snell <[email protected]>
Refs: #12170 PR-URL: #12317 Reviewed-By: James M Snell <[email protected]>
gibfahn commented May 15, 2017
ping @vsemozhetbyt , should this be backported to v6.x? |
vsemozhetbyt commented May 15, 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.
@gibfahn I am not sure. If we have some +1 I can try to backport though if this does not land cleanly. |
gibfahn commented Jun 17, 2017
I suspect that it's not worth trying to backport any more complex performance improvements to v6.x, all the benchmarks will have to be rerun etc. Having said that, if anyone is willing to do the work, then by all means do backport perf improvements. |
Checklist
Affected core subsystem(s)
benchmark
This change is mostly for readability as the edited fragments are not performance-wise concerned. However, a benchmark to compare both ways of long string creation is added to be on the safe side.
Results of the added benchmark with the last
node.8.0.0-nightly20170402