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.
Description
Description
Event Timeline
Comment Actions
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.
Comment Actions
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.
Results:
- 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.