mediawiki-extensions-CodeMi.../resources/mode
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
..
mediawiki Fix performance bottleneck in mediawiki syntax highlighter 2021-01-13 16:58:57 +01:00