In Lexer.js, WSL uses the following code to find the line number of an index into the source string:
lineNumberForIndex(index)
{
let matches = this._text.substring(0, index).match(/\n/g);
return (matches ? matches.length : 0) + this._lineNumberOffset;
}
lineNumberForIndex is called more than 40000 times over the course of the benchmark. This approach is linear in the length of the source string, making the overall cost of lineNumberForIndex quadratic.
In SpiderMonkey, this function is ~15% of the entire benchmark. V8 and JSC have each added "a caching mechanism to optimize repeated matching of global atomic regular expressions on growing substrings". This is a significant win on this workload, but is quite unlikely to be relevant in real-world code. AFAICT, WSL was written specifically for JetStream 2, and is not based on an existing framework. Unless I'm missing a reason that we should expect this cache to be useful in the wild, we should rewrite this code.
In Lexer.js, WSL uses the following code to find the line number of an index into the source string:
lineNumberForIndex is called more than 40000 times over the course of the benchmark. This approach is linear in the length of the source string, making the overall cost of lineNumberForIndex quadratic.
In SpiderMonkey, this function is ~15% of the entire benchmark. V8 and JSC have each added "a caching mechanism to optimize repeated matching of global atomic regular expressions on growing substrings". This is a significant win on this workload, but is quite unlikely to be relevant in real-world code. AFAICT, WSL was written specifically for JetStream 2, and is not based on an existing framework. Unless I'm missing a reason that we should expect this cache to be useful in the wild, we should rewrite this code.