-
Notifications
You must be signed in to change notification settings - Fork 30.1k
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
test: fix RegExp nits #13770
test: fix RegExp nits #13770
Conversation
RegExp part with a quantifier '0 or more' is redundant if it is used at the very edge of the RegExp and is not captured or does not affect match indices.
In fixed case, `/g` flag is needless in the boolean context.
Use non-capturing grouping or remove capturing completely when: * capturing is useless per se, e.g. in test() check; * captured groups are not used afterward at all; * some of the later captured groups are not used afterward.
match() and exec() return a complicated object, unneeded in a boolean context.
This commit takes RegExp creation out of cycles and other repetitions. As long as the RegExp does not use /g flag and match indices, we are safe here. In tests, this fix hardly gives a significant performance gain, but it increases clarity and maintainability, reassuring some RegExps to be identical. RegExp in functions are not taken out of their functions: while these functions are called many times and their RegExps are recreated with each call, the performance gain in test cases does not seem to be worth decreasing function self-dependency.
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.
LGTM if the CI passes (it's looking good so far).
@@ -22,7 +22,7 @@ function checkListResponse(instance, err, response) { | |||
const match = wsUrl.match(/^ws:\/\/(.*):9229\/(.*)/); | |||
assert.strictEqual(ip, match[1]); | |||
assert.strictEqual(res['id'], match[2]); | |||
assert.strictEqual(ip, res['devtoolsFrontendUrl'].match(/.*ws=(.*):9229/)[1]); | |||
assert.strictEqual(ip, res['devtoolsFrontendUrl'].match(/ws=(.*):9229/)[1]); |
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.
This change actually can have an effect on the match returned:
const string = 'ws=0.0.0.0:9229 ws=1.1.1.1:9229';
string.match(/.*ws=(.*):9229/)[1] // => '1.1.1.1'
string.match(/ws=(.*):9229/)[1] // => '0.0.0.0:9229 ws=1.1.1.1'
I'm not sure whether this matters for this particular test case.
[EDITED by @Trott to correct small typo in code: 9299 -> 9229]
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.
Oh, sorry, I've missed this part can take up similar parts.
However, this RegExp checks a URL like:
chrome-devtools://devtools/bundled/inspector.html?experiments=true&v8only=true&ws=192.168.137.2:9229/151fc61d-6045-4692-b651-58bb5ba2c83d
If there is any chance this URL can have two ws=
parts, let me know and I will remove this commit.
cc @nodejs/v8-inspector
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.
I would leave it as is. If there's no good reason to make the test more lax, don't make it more lax. :-D
If the intention is to introduce a lint rule that would flag something like this line, it can always be disabled on just this line with a comment.
* Remove needless RegExp flag In fixed case, `/g` flag is needless in the boolean context. * Remove needless RegExp capturing Use non-capturing grouping or remove capturing completely when: * capturing is useless per se, e.g. in test() check; * captured groups are not used afterward at all; * some of the later captured groups are not used afterward. * Use test, not match/exec in boolean context match() and exec() return a complicated object, unneeded in a boolean context. * Do not needlessly repeat RegExp creation This commit takes RegExp creation out of cycles and other repetitions. As long as the RegExp does not use /g flag and match indices, we are safe here. In tests, this fix hardly gives a significant performance gain, but it increases clarity and maintainability, reassuring some RegExps to be identical. RegExp in functions are not taken out of their functions: while these functions are called many times and their RegExps are recreated with each call, the performance gain in test cases does not seem to be worth decreasing function self-dependency. PR-URL: #13770 Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Landed in 76340e3 (the first commit was dropped according to the request). |
* Remove needless RegExp flag In fixed case, `/g` flag is needless in the boolean context. * Remove needless RegExp capturing Use non-capturing grouping or remove capturing completely when: * capturing is useless per se, e.g. in test() check; * captured groups are not used afterward at all; * some of the later captured groups are not used afterward. * Use test, not match/exec in boolean context match() and exec() return a complicated object, unneeded in a boolean context. * Do not needlessly repeat RegExp creation This commit takes RegExp creation out of cycles and other repetitions. As long as the RegExp does not use /g flag and match indices, we are safe here. In tests, this fix hardly gives a significant performance gain, but it increases clarity and maintainability, reassuring some RegExps to be identical. RegExp in functions are not taken out of their functions: while these functions are called many times and their RegExps are recreated with each call, the performance gain in test cases does not seem to be worth decreasing function self-dependency. PR-URL: #13770 Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
This does not land cleanly in LTS. Please feel free to manually backport. Please also feel free to replace the backport request label with do-not-land if it shouldn't land |
@MylesBorins Backport: #14370 |
* Remove needless RegExp flag In fixed case, `/g` flag is needless in the boolean context. * Remove needless RegExp capturing Use non-capturing grouping or remove capturing completely when: * capturing is useless per se, e.g. in test() check; * captured groups are not used afterward at all; * some of the later captured groups are not used afterward. * Use test, not match/exec in boolean context match() and exec() return a complicated object, unneeded in a boolean context. * Do not needlessly repeat RegExp creation This commit takes RegExp creation out of cycles and other repetitions. As long as the RegExp does not use /g flag and match indices, we are safe here. In tests, this fix hardly gives a significant performance gain, but it increases clarity and maintainability, reassuring some RegExps to be identical. RegExp in functions are not taken out of their functions: while these functions are called many times and their RegExps are recreated with each call, the performance gain in test cases does not seem to be worth decreasing function self-dependency. Backport-PR-URL: #14370 PR-URL: #13770 Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
* Remove needless RegExp flag In fixed case, `/g` flag is needless in the boolean context. * Remove needless RegExp capturing Use non-capturing grouping or remove capturing completely when: * capturing is useless per se, e.g. in test() check; * captured groups are not used afterward at all; * some of the later captured groups are not used afterward. * Use test, not match/exec in boolean context match() and exec() return a complicated object, unneeded in a boolean context. * Do not needlessly repeat RegExp creation This commit takes RegExp creation out of cycles and other repetitions. As long as the RegExp does not use /g flag and match indices, we are safe here. In tests, this fix hardly gives a significant performance gain, but it increases clarity and maintainability, reassuring some RegExps to be identical. RegExp in functions are not taken out of their functions: while these functions are called many times and their RegExps are recreated with each call, the performance gain in test cases does not seem to be worth decreasing function self-dependency. Backport-PR-URL: #14370 PR-URL: #13770 Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
* Remove needless RegExp flag In fixed case, `/g` flag is needless in the boolean context. * Remove needless RegExp capturing Use non-capturing grouping or remove capturing completely when: * capturing is useless per se, e.g. in test() check; * captured groups are not used afterward at all; * some of the later captured groups are not used afterward. * Use test, not match/exec in boolean context match() and exec() return a complicated object, unneeded in a boolean context. * Do not needlessly repeat RegExp creation This commit takes RegExp creation out of cycles and other repetitions. As long as the RegExp does not use /g flag and match indices, we are safe here. In tests, this fix hardly gives a significant performance gain, but it increases clarity and maintainability, reassuring some RegExps to be identical. RegExp in functions are not taken out of their functions: while these functions are called many times and their RegExps are recreated with each call, the performance gain in test cases does not seem to be worth decreasing function self-dependency. Backport-PR-URL: #14370 PR-URL: #13770 Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
test
It will be easier to review this PR commit by commit, performance-wise and for better comprehending (different changes are confusingly interwoven in the overall diff).
Remove redundant
RegExp
part.RegExp
part with a quantifier '0 or more times' is redundant if it is used at the very edge of theRegExp
and is not captured or does not affect match indices (UPD: and should not greedily take up previous similar parts).Remove needless
RegExp
flag.In fixed case,
/g
flag is needless in the boolean context.Remove needless
RegExp
capturing.Use non-capturing grouping or remove capturing completely when:
test()
check;Use
test()
, notmatch()
orexec()
in boolean context.match()
andexec()
return a complicated object, unneeded in a boolean context. This fix also makes the code more clear and predictable.Do not needlessly repeat
RegExp
creation.This is the largest commit, however, it is rather easy to skim. It takes
RegExp
creation out of cycles and other repetitions.As long as the
RegExp
does not use/g
flag + match indices, we are safe here.In tests, this fix hardly gives a significant performance gain, but it increases clarity and maintainability, reassuring some
RegExp
s to be identical.RegExp
s in functions are not taken out of their functions: while these functions are called many times and their RegExps are recreated with each call, the performance gain in test cases does not seem to be worth decreasing function self-dependency.