perf: more precise check for < or > in mustacheTag #2213
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Part of #2179
The reproduction of #2179 has a large HTML without any moustache or control flow blocks. So, the
lastIndexOf
check has to search through nearly the entire template part before the start position in every start tag/ end tag. But we only need to check the HTML's last "Content" part before the<
or>
. This will make thelastIndexOf
checking way shorter string. Is there any other part we might need to check?The perf difference in most files I tested is around
±10%
, and most are within 1 ms, so it's not a big difference, even if it is slightly slower in some cases. But In the reproduction, the preprocess went from nearly1000ms
to10ms
.I only apply the optimization to HTML content because attribute value might have whitespace. The scanner would treat it as a whitespace between attributes. For example,
The scanner might parse it as
on:click={()
,=
{}}
. We might need a proper js/ts parser or scanner to know when the attribute ends. It can be more expensive since we need to check for every attribute with a js expression and can't lazily check only when there is a>
. This is also part of the reason #2155 is a bit hard to fix.