src/technologies/g.json:
"Grafana": {
"scripts": [".+latestVersion\":\"[\\d\\.\\w\\-]+\"\\,\"version\":\"([\\d\\.]+)\;version:\\1\;confidence:75"]
}The leading .+ is redundant under a search() and makes a non-matching input backtrack across the entire haystack.
Measured
Analysing demandsphere.com, this single pattern took 178.84s of a 181.2s run, against one 397 KB script body. Profile attributed 185s of 33,329 re.Pattern.search calls to it. With the pattern removed the same page analyses in 874ms.
That is a Python re measurement, so the absolute number will differ in a JS engine, but the shape is the same: a leading unbounded quantifier on a pattern that usually does not match is pathological in any backtracking engine.
Note
enthec/webappanalyzer's copy of the same rule has no leading .+, so the two datasets have diverged here and this side carries the slow variant.
Suggested fix
Drop the leading quantifier. search() already scans, so the pattern behaves identically without it:
"scripts": ["latestVersion\":\"[\\d\\.\\w\\-]+\"\\,\"version\":\"([\\d\\.]+)\;version:\\1\;confidence:75"]
Also, separately
Shaka Player's js value v([\d\.-\w]+)\;version:\1 is not a valid character class (\.-\w is a bad range) and fails to compile in Python, so that rule is silently dead for any Python consumer. It happens to be tolerated by JS. Probably wants [\d\.\w-]+.
Both found by a linter run over both datasets while building a matcher; happy to send a PR.
src/technologies/g.json:The leading
.+is redundant under asearch()and makes a non-matching input backtrack across the entire haystack.Measured
Analysing demandsphere.com, this single pattern took 178.84s of a 181.2s run, against one 397 KB script body. Profile attributed 185s of 33,329
re.Pattern.searchcalls to it. With the pattern removed the same page analyses in 874ms.That is a Python
remeasurement, so the absolute number will differ in a JS engine, but the shape is the same: a leading unbounded quantifier on a pattern that usually does not match is pathological in any backtracking engine.Note
enthec/webappanalyzer's copy of the same rule has no leading.+, so the two datasets have diverged here and this side carries the slow variant.Suggested fix
Drop the leading quantifier.
search()already scans, so the pattern behaves identically without it:Also, separately
Shaka Player'sjsvaluev([\d\.-\w]+)\;version:\1is not a valid character class (\.-\wis a bad range) and fails to compile in Python, so that rule is silently dead for any Python consumer. It happens to be tolerated by JS. Probably wants[\d\.\w-]+.Both found by a linter run over both datasets while building a matcher; happy to send a PR.