Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Regex FindFirstChar optimization for a setloopatomic followed by a literal #62445

Closed
stephentoub opened this issue Dec 6, 2021 · 1 comment · Fixed by #63477
Closed
Assignees
Milestone

Comments

@stephentoub
Copy link
Member

Regex has a variety of vectorized approaches to quickly skipping to the first character that might possibly start a match. For example, given "\shi", it will likely IndexOf('h') and then back off one character. However, given an expression like "(\w+)://", where the literals in the expression are a variable distance from the beginning of the match, it won't currently employ any vectorized searching and will instead walk each character checking it against being a word char (\w). We could, however, optimize a subset of these cases, in particular where we have a setloopatomic (potentially in a capture) followed by a literal that's not part of the set; there, we can IndexOf for the literal and then walk backwards from the literal as long as the prior characters are in the set. A prototype of this shows huge gains on benchmarks like https://github.com/mariomka/regex-benchmark/blob/17d073ec864931546e2694783f6231e4696a9ed4/csharp/Benchmark.cs#L23. The main downside is we'll end up paying double the cost for the set lookups, once backwards in FindFirstChar, once forwards in Go, unless we can successfully pass more information from FindFirstChar to Go to signal where that setloopatomic ends.

@stephentoub stephentoub added this to the 7.0.0 milestone Dec 6, 2021
@ghost
Copy link

ghost commented Dec 6, 2021

Tagging subscribers to this area: @dotnet/area-system-text-regularexpressions
See info in area-owners.md if you want to be subscribed.

Issue Details

Regex has a variety of vectorized approaches to quickly skipping to the first character that might possibly start a match. For example, given "\shi", it will likely IndexOf('h') and then back off one character. However, given an expression like "(\w+)://", where the literals in the expression are a variable distance from the beginning of the match, it won't currently employ any vectorized searching and will instead walk each character checking it against being a word char (\w). We could, however, optimize a subset of these cases, in particular where we have a setloopatomic (potentially in a capture) followed by a literal that's not part of the set; there, we can IndexOf for the literal and then walk backwards from the literal as long as the prior characters are in the set. A prototype of this shows huge gains on benchmarks like https://github.com/mariomka/regex-benchmark/blob/17d073ec864931546e2694783f6231e4696a9ed4/csharp/Benchmark.cs#L23. The main downside is we'll end up paying double the cost for the set lookups, once backwards in FindFirstChar, once forwards in Go, unless we can successfully pass more information from FindFirstChar to Go to signal where that setloopatomic ends.

Author: stephentoub
Assignees: -
Labels:

area-System.Text.RegularExpressions, tenet-performance

Milestone: 7.0.0

@dotnet-issue-labeler dotnet-issue-labeler bot added the untriaged New issue has not been triaged by the area owner label Dec 6, 2021
@joperezr joperezr removed the untriaged New issue has not been triaged by the area owner label Dec 15, 2021
@ghost ghost added the in-pr There is an active PR which will close this issue when it is merged label Jan 6, 2022
@stephentoub stephentoub self-assigned this Jan 6, 2022
@ghost ghost removed the in-pr There is an active PR which will close this issue when it is merged label Jan 15, 2022
@ghost ghost locked as resolved and limited conversation to collaborators Feb 14, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants