-
Notifications
You must be signed in to change notification settings - Fork 12.2k
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
perf: improve regexp performance by using non-capturing groups #58551
base: main
Are you sure you want to change the base?
Conversation
This PR doesn't have any linked issues. Please open an issue that references this PR. From there we can discuss and prioritise. |
Funnily I was already about to send a PR similar to this one using the findings from https://www.npmjs.com/package/eslint-plugin-regexp. @typescript-bot test it |
Actually, this PR is perpendicular as it affects dynamically created regexes. Very nice! |
@jakebailey Here are the results of running the user tests comparing Everything looks good! |
Hey @jakebailey, the results of running the DT tests are ready. Everything looks the same! |
@jakebailey Here they are:
tscComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
Developer Information: |
Perf looks unaffected, I'm afraid. |
@jakebailey Here are the results of running the top 400 repos comparing Everything looks good! |
This PR is a performance improvement to TS cli/compiler for RegExps of file path matching. Currently, it uses dynamically constructed regex with groups to match multiple path patterns. While all RegExp groups are capturing, but we only use
regex.test(file)
function, which doesn't consume those groups at all.I am building a RegExp monitor regex-doctor and found those regexes are taking quite some time to do the matches, even in a very small project. I imagine the cost of running those regexes could scale up with the package size.
For example, in my testing repo, this regex cost a total
8.48ms
to match against 17 paths (and crates aRegexMatchArray
with 233 unconsumed groups in this case)After this PR, the time cost to match with the exact same inputs becomes
3.36ms
(60% faster on regex matching).Can you help to initiate the bot to run a proper benchmark and see how it would help the overall performance? Thanks.