-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
src,tools: use template literals #5778
Conversation
LGTM |
|
||
rules: | ||
# suggest using template literals instead of string concatenation | ||
prefer-template: 2 |
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.
Missing new line at EOF
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.
Rebased, added newline per @targos, and force pushed.
One nit, but LGTM if CI is happy |
LGTM |
Many of these are only doing the string templating at the beginning or at the end. Maybe this has changed and I missed it- but I thought doing concatenation was faster. I admit- these paths are probably not hit too much, but it seems that ALL thing performance get nits ;) |
None of the paths are hot and I think template strings except where justified specifically by perf makes sense. LGTM and +1 |
Convert string concatenation to template literals. Enforce with lint rule.
@williamkapke wrote:
With the caveat that I may simply be doing the benchmark wrong, my tests are showing that template literals are faster. Here's the code. (You'll have to
And here are the results I'm getting with Node.js v5.9.0:
Not that it really matters because, as @benjamingr points out, none of this is in a hot path.
That has not been my experience. On the contrary, PRs with micro-optimizations on non-hot-path code and with no benchmark showing effectiveness are usually rejected on the grounds that they cause churn and reduce code readability for no measurable benefit. |
Template strings should be equally fast. They are desugared to string concatenation by V8's parser |
LGTM |
Cheers f158a86 |
Convert string concatenation to template literals. Enforce with lint rule. PR-URL: #5778 Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Johan Bergström <[email protected]>
Heh, whoops, looks like I flipped the labels in my test. What I have listed for string concatenation was actually for template literals and vice versa. String concatenation seems to be somewhere between 9% and 18% faster, at least on the machines I have available to test on, and using Node.js 5.9.0. Not enough to worry about for things that only happen once, but probably enough to think twice about extreme hot-path code. |
Prefer the use of template string literals over string concatenation in the dns module, makes dns consistent with other modules basically doing nodejs#5778 for it. PR-URL: nodejs#5809 Reviewed-By: James M Snell <[email protected]>
Prefer the use of template string literals over string concatenation in the dns module, makes dns consistent with other modules basically doing #5778 for it. PR-URL: #5809 Reviewed-By: James M Snell <[email protected]>
This rule will be completely invalid as of #5103 |
@Fishrock123 mind elaborating? Which rule? |
@Fishrock123 I checked out your |
Convert string concatenation to template literals. Enforce with lint rule. PR-URL: #5778 Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Johan Bergström <[email protected]> Conflicts: src/.eslintrc src/node.js
Prefer the use of template string literals over string concatenation in the dns module, makes dns consistent with other modules basically doing #5778 for it. PR-URL: #5809 Reviewed-By: James M Snell <[email protected]>
Prefer the use of template string literals over string concatenation in the dns module, makes dns consistent with other modules basically doing #5778 for it. PR-URL: #5809 Reviewed-By: James M Snell <[email protected]>
I'm not 100% convinced this should be backported. @Trott it isn't landing cleanly, would you be willing to manually backport, do you think it is necessary? |
Prefer the use of template string literals over string concatenation in the dns module, makes dns consistent with other modules basically doing #5778 for it. PR-URL: #5809 Reviewed-By: James M Snell <[email protected]>
Willing to: Sure. Necessary: Meh, could go either way. Here's the PR if you want it: #5960 (If you're not going to use it, just go ahead and close it.) |
thanks @Trott |
Prefer the use of template string literals over string concatenation in the dns module, makes dns consistent with other modules basically doing #5778 for it. PR-URL: #5809 Reviewed-By: James M Snell <[email protected]>
Convert string concatenation to template literals. Enforce with lint rule. PR-URL: nodejs#5778 Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Johan Bergström <[email protected]>
Convert string concatenation to template literals. Enforce with lint rule. PR-URL: #5778 Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Johan Bergström <[email protected]>
Pull Request check-list
make -j8 test
(UNIX) orvcbuild test nosign
(Windows) pass withthis change (including linting)?
test (or a benchmark) included?
existing APIs, or introduces new ones)?
Affected core subsystem(s)
src, tools
Description of change
Convert string concatenation to template literals. Enforce with lint
rule.
This came out of the conversation around #5762. If this is not objectionable, then the idea would be to enable the
prefer-template
rule on other parts of the codebase, moving it incrementally to using template literals instead of string concatenation.