Thiemo Kreuz f1cf1a534c Fix performance bottleneck in mediawiki syntax highlighter ... I continued profiling the matchbrackets addon for T270237 and run into performance issues that turned out to be unrelated to the addon. The flame graph highlighted a "match" function. Note this is not the String.match() from JavaScript, but something in the CodeMirror lib: StringStream.prototype.match = function (pattern) { var match = this.string.match(pattern); if (match && match.index > 0) { return null; } return match; } (Note: I simplified this code so we can focus on the bug.) When the pattern is a regular expression, it's executed via JavaScript's String.match(). The function then checks if there was a match and if it's at the start of the string. If not, it's not a match and doesn't return one. In other words: Even if there is a match somewhere in the string, the function acts as if there was no match. When we change all patterns to be anchored via ^, they don't scan the entire string any more but return much ealier when there is no match at the start of the string. We are effectively replacing nested loops (hidden in the patterns) with single calls. This bug exists since 2014. The disabled line in the matchbrackets addon is just dead code. I don't remove it to document the fact that we disabled it. Bug: T270237 Bug: T270317 Change-Id: Icbb1122e6a3b26c0606726ff405e108931d185be		2021-01-13 16:58:57 +01:00
..
matchbrackets.js	Fix performance bottleneck in mediawiki syntax highlighter	2021-01-13 16:58:57 +01:00