-
Notifications
You must be signed in to change notification settings - Fork 5.3k
Skip RegexOptions.NonBacktracking phase 3 for some patterns #65531
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
Conversation
If a pattern doesn't have any captures and if any match of that pattern will always be the same length, we can skip the Phase 3 computation as, given the computed starting position of the match, we know exactly where it's going to end.
|
Tagging subscribers to this area: @dotnet/area-system-text-regularexpressions Issue DetailsIf a pattern doesn't have any captures and if any match of that pattern will always be the same length, we can skip the Phase 3 computation as, given the computed starting position of the match, we know exactly where it's going to end. Also took the opportunity to add some comments. Fixes #65383 (mostly)
|
....Text.RegularExpressions/src/System/Text/RegularExpressions/Symbolic/SymbolicRegexMatcher.cs
Show resolved
Hide resolved
....Text.RegularExpressions/src/System/Text/RegularExpressions/Symbolic/SymbolicRegexMatcher.cs
Show resolved
Hide resolved
| if (startat == input.Length) | ||
| { | ||
| // Covers the special-case of an empty match at the end of the input. | ||
| uint prevKind = GetCharKind(input, startat - 1); | ||
| uint nextKind = GetCharKind(input, startat); | ||
|
|
||
| bool emptyMatchExists = _pattern.IsNullableFor(CharKind.Context(prevKind, nextKind)); | ||
| return emptyMatchExists ? | ||
| return _pattern.IsNullableFor(CharKind.Context(prevKind, nextKind)) ? | ||
| new SymbolicMatch(startat, 0) : | ||
| SymbolicMatch.NoMatch; | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at the new comment I realized this optimization should additionally handle the case where there are capture groups and do the same ApplyEffects thing FindEndPositionCapturing is doing. The difference will be visible for some patterns with nullable capture groups that have anchors in them.
Edit: Oh actually any nullable patterns with nullable capture groups.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, @olsaarik. That's pre-existing this PR, yes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, shouldn't block this PR, just something I noticed.
|
Improvements in dotnet/perf-autofiling-issues#3665, dotnet/perf-autofiling-issues#3672 |
If a pattern doesn't have any captures and if any match of that pattern will always be the same length, we can skip the Phase 3 computation as, given the computed starting position of the match, we know exactly where it's going to end.
Also took the opportunity to add some comments.
Fixes #65383 (mostly... I think the rest is #65532)