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

Investigate benefit of computing max regex match length #62697

Closed
stephentoub opened this issue Dec 13, 2021 · 3 comments · Fixed by #64177
Closed

Investigate benefit of computing max regex match length #62697

stephentoub opened this issue Dec 13, 2021 · 3 comments · Fixed by #64177
Assignees
Milestone

Comments

@stephentoub
Copy link
Member

Today we compute the minimum length an input is required to be to match an expression; that's then used in a variety of ways, e.g. checking the input length and failing immediately if we've reached a point where the remaining input is shorter than required. We could also in some situations compute a maximum length. This could have various benefits, in particular if the expression ends with a $ anchor and isn't anchored at the beginning, if the current positron is less than the max match length from the end, we can just jump forward to that position, potentially saving on large amounts of unnecessary match attempts. We'd want to investigate how common this is, though, to determine if it's worth the extra compute time.

@ghost
Copy link

ghost commented Dec 13, 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

Today we compute the minimum length an input is required to be to match an expression; that's then used in a variety of ways, e.g. checking the input length and failing immediately if we've reached a point where the remaining input is shorter than required. We could also in some situations compute a maximum length. This could have various benefits, in particular if the expression ends with a $ anchor and isn't anchored at the beginning, if the current positron is less than the max match length from the end, we can just jump forward to that position, potentially saving on large amounts of unnecessary match attempts. We'd want to investigate how common this is, though, to determine if it's worth the extra compute time.

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 13, 2021
@danmoseley
Copy link
Member

worth the extra compute time.

My assumption was that the analyses we do before kicking off the engine take negligible time - is that not right? would this be especially expensive?

of course, in a generator, it's "free".

@stephentoub
Copy link
Member Author

My assumption was that the analyses we do before kicking off the engine take negligible time - is that not right? would this be especially expensive?

Negligible compared to performing a match many, many times? Yes. Negligible on the startup path / performing a match once? No.

of course, in a generator, it's "free".

We can have a higher budget, but it still impacts compilation time, which is something we do care about.

@joperezr joperezr removed the untriaged New issue has not been triaged by the area owner label Dec 13, 2021
@stephentoub stephentoub self-assigned this Jan 21, 2022
@ghost ghost added the in-pr There is an active PR which will close this issue when it is merged label Jan 24, 2022
@ghost ghost removed the in-pr There is an active PR which will close this issue when it is merged label Jan 25, 2022
@ghost ghost locked as resolved and limited conversation to collaborators Feb 25, 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.

3 participants