Support template literals for nested calls#392
Conversation
|
I don’t see any mention of performance here. Please see the concerns in the issue. |
|
You're right, sorry. In the usual code execution only one if-clause extra is checked: This clause is only triggered when the function (e.g. |
|
|
|
Using 'npm run bench'. These are the results |
|
Are there still issues with this PR? |
|
Can you add some tests to the benchmark using template literals and nesting? Could be useful for the future. |
|
This also needs to be documented in the readme and index.d.ts. |
|
I meant docs-wise. The readme and index.d.ts should be in sync docs-wise. |
|
Is it okay like this? |
|
@toonijn I don't understand your question. I already commented what needs to be done. |
|
I think I've implemented the changes in my latest commit. |
|
I already commented that. What you added to the readme, you need to add to index.d.ts too (docs-wise). |
|
@sindresorhus A small example is included in index.d.ts as well. |
|
I'm ok with this. |
Qix-
left a comment
There was a problem hiding this comment.
A few nits, but otherwise lgtm.
source/index.js
Outdated
|
|
||
| const createBuilder = (self, _styler, _isEmpty) => { | ||
| const builder = (...arguments_) => { | ||
| if (Array.isArray(arguments_[0])) { |
There was a problem hiding this comment.
| if (Array.isArray(arguments_[0])) { | |
| if (Array.isArray(arguments_[0]) && arguments_[0].raw) { |
There was a problem hiding this comment.
Otherwise, this would break any sort of usecase where people are relying on array -> string coercion.
There was a problem hiding this comment.
^ Would be good to have a test for this too.
There was a problem hiding this comment.
It migh also be a good idea to cache Array.isArray in a module scope const to minimise [[Get]] lookups of a mutable property:
| if (Array.isArray(arguments_[0])) { | |
| if (ArrayIsArray(arguments_[0]) && ArrayIsArray(arguments_[0].raw)) { |
There was a problem hiding this comment.
- I added a small test to see if chalk correctly casts int and array to string. This revealed a previously existing bug:
chalk(["abc"])threw an error. This should now be fixed by adding the suggestion on line 198 as wellLine 198 in 26c73d2
- Caching Array.isArray is indeed faster. (from 24M ops/s to 25M ops/s for the first benchmark).
| chalkBgRed(blueStyledString); | ||
| }); | ||
|
|
||
| set('iterations', 10000); |
There was a problem hiding this comment.
Why manually set iterations here? This can skew results if too low.
There was a problem hiding this comment.
Parsing strings for the special {bold ...}-syntax is a lot slower.
Benchmark 'cached: 1 style' is almost 200 times faster than 'cached: 1 style template literal'. So I reduced the number of iterations accordingly.
Better than specifying the number of iterations would be to set a minimal runtime for each benchmark. So instead of
Line 6 in 26c73d2
something like
set('mintime', 500);
But this feels out of the scope of this PR.
There was a problem hiding this comment.
Better than specifying the number of iterations would be to set a minimal runtime for each benchmark.
I agree. Mind opening a PR? :)
Qix-
left a comment
There was a problem hiding this comment.
LGTM
Drawing attention to this comment, though: #392 (comment)
Fixes #341
Closes #398
Closes #380
Example:
IssueHunt Summary
Referenced issues
This pull request has been submitted to:
IssueHunt has been backed by the following sponsors. Become a sponsor