Look for performance impacts of highlighting tags from the middle or the beginning or end of a large section, or in a document with deeply nested tags. From the initial investigation T254976: Investigation: Bracket matching , it was estimated that this feature may be too slow on large chunks of text.
|Open||None||T280023 Enable bracket matching on all wikis|
|Resolved||Lena_WMDE||T273591 Enable bracket matching on more wikis|
|Resolved||Lena_WMDE||T270238 Enable bracket matching on the first wikis|
|Resolved||Lena_WMDE||T243835 Investigation: Check CodeMirror's capabilities for more "distinct" syntax highlighting|
|Resolved||Tobi_WMDE_SW||T270240 Try to write a browser test for the bracket matching feature|
|Resolved||thiemowmde||T270317 Optimization and limits for bracket matching|
|Resolved||lilients_WMDE||T261857 Implement bracket matching in CodeMirror behind a feature flag|
|Resolved||Spike||thiemowmde||T254976 Investigation: Bracket matching|
|Resolved||Spike||awight||T259700 Investigation: scope bracket matching and tag matching add-ons|
|Resolved||Spike||thiemowmde||T259701 Test performance impacts of highlighting brackets for a large section of content|
|Resolved||Spike||awight||T260249 Test performance impacts of highlighting tags for a large section of content|
This is based on a different add-on – one I have not reviewed yet. But I believe what I wrote in T259701#6385402 mostly applies as well. To summarize:
- I believe the add-on first checks if the cursor is on a tag.
- If it is, it checks if it's an open or closing tag, and scans for the matching one in the correct direction.
- To support highlighting "from the middle" we need to scan in both directions, skipping nested tags, and stopping when an opening and a closing tag was found. Highlight them. Additionally highlight them as errors if they don't match.
- The performance impact should be the same as in T259701. The actual scan performs as the old one, but it is executed all the time, not only then the cursor is on a tag.
There is virtually no overhead or lag for this add-on, regardless of text size. I tried:
- 1000 nested <div> blocks.
- Two tags, followed by 10k lines of text (680kB) created by xxd urandom, finally two close tags.
- Same as above document, but with the inner tag mismatched.
- Updates are imperceptibly lagged, and complete within a fraction of the auto-keyrepeat period. In other words, holding down the arrow button behaves nicely.
- Instrumenting doMatchTags shows an overhead of mean 5 µs, max 30µs per cursor motion for the deeply-nested document, and ~2µs for the long-content document.
- Mismatched tags perform the same as matched tags.
- Low CPU usage, overall ~5% to run the cursor through these documents.