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

Literals optimization #2

Open
nitely opened this issue Aug 10, 2020 · 0 comments
Open

Literals optimization #2

nitely opened this issue Aug 10, 2020 · 0 comments

Comments

@nitely
Copy link
Owner

nitely commented Aug 10, 2020

nim-regex implements a literals optimization that puts it on par with PCRE performance. This is only because the nim-regex NFA engine is pretty slow, as it's is 35x times faster than PCRE in one of the benchmarks where the NFA is not hit much. I think, nregex would be consistently faster than PCRE once the optimization is in place.

However, both find/findAll APIs have quadratic time worst case complexity (linear time best case, though). Granted, PCRE has the same issue in the same situations (and many more). A linear time version would require to track all possible matching states in parallel (NFA style), and it would be slower. Another way may be to transform the expression into re".*regex" where "regex" is the expression, and "dot" matches new lines, that way the regex can start anywhere in the string.

That said, nregex is just a PoC to play around DFAs, so I doubt I'll ever implement this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant