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

net: make isIPv4 and isIPv6 more efficient #5478

Closed
wants to merge 1 commit into from

Conversation

vkurchatkin
Copy link
Contributor

Pull Request check-list

  • Does make -j8 test (UNIX) or vcbuild test nosign (Windows) pass with
    this change (including linting)?
  • Is the commit message formatted according to [CONTRIBUTING.md][0]?
  • If this change fixes a bug (or a performance problem), is a regression
    test (or a benchmark) included?
  • Is a documentation update included (if this change modifies
    existing APIs, or introduces new ones)?

Affected core subsystem(s)

net

Description of change

isIPv4 and isIPv6 are implemented on top of isIP, which in turn
checks the sting for being both IPv4 and IPv6, which can be inefficient
in some scenarios. This commit makes them use uv_inet_pton directly
instead.

@@ -1087,6 +1087,27 @@ static void IsIP(const FunctionCallbackInfo<Value>& args) {
args.GetReturnValue().Set(rc);
}

static void IsIPv4(const FunctionCallbackInfo<Value>& args) {
node::Utf8Value ip(args.GetIsolate(), args[0]);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need a check that args[0] is a string here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think so. Utf8Value calls ToString under the hood, should be fine.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe include a test passing null, an object, and a number? Just a suggestion

@evanlucas
Copy link
Contributor

LGTM with a suggestion

@evanlucas
Copy link
Contributor

@@ -1563,12 +1563,12 @@ exports.isIP = cares.isIP;


exports.isIPv4 = function(input) {
return exports.isIP(input) === 4;
return cares.isIPv4(input);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason why you don't just assign it as exports.isIPv4 = cares.isIPv4; ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No particular reason, but I've just added check for symbol in js, so wrapper is necessary

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about now?

@mscdex mscdex added the net Issues and PRs related to the net subsystem. label Feb 28, 2016
@vkurchatkin
Copy link
Contributor Author

Added some tests and also support for symbols. PTAL

@evanlucas
Copy link
Contributor

Still LGTM. I think the symbol changes should make it semver-major though.

@evanlucas evanlucas added the semver-major PRs that contain breaking changes and should be released in the next major version. label Feb 29, 2016
@vkurchatkin
Copy link
Contributor Author

@evanlucas well, I don't think so. It seems like an oversight, so just a bug.

@silverwind
Copy link
Contributor

Do we really expect people to pass symbols to APIs that are expecting a string? I think this check there is penaltizing the common case. Otherwise LGTM.

@evanlucas
Copy link
Contributor

I think the additional checks for symbols should be in a separate pr/commit since those should be semver-major. We are going from throwing an error, to not throwing an error. The performance changes should be in it's own commit, so it can be backported. Thoughts?

@vkurchatkin
Copy link
Contributor Author

I think the additional checks for symbols should be in a separate pr/commit

Definitely, it's not hard.

We are going from throwing an error, to not throwing an error

It's exactly what bug fixing usually does :-)

@jasnell
Copy link
Member

jasnell commented Mar 2, 2016

LGTM

`isIPv4` and `isIPv6` are implemented on top of `isIP`, which in turn
checks the sting for being both IPv4 and IPv6, which can be inefficient
in some scenarios. This commit makes them use `uv_inet_pton` directly
instead.
@vkurchatkin vkurchatkin removed the semver-major PRs that contain breaking changes and should be released in the next major version. label Mar 13, 2016
@vkurchatkin
Copy link
Contributor Author

Removed controversial commit, squashed and rebased. PTAL

@jasnell
Copy link
Member

jasnell commented Mar 14, 2016

Still LGTM

@evanlucas
Copy link
Contributor

LGTM

1 similar comment
@cjihrig
Copy link
Contributor

cjihrig commented Mar 14, 2016

LGTM

@jasnell
Copy link
Member

jasnell commented Mar 14, 2016

Marking this as a watch for v4 but want to hold off a bit before landing, just to be safe. /cc @thealphanerd

@jasnell
Copy link
Member

jasnell commented Mar 14, 2016

@silverwind
Copy link
Contributor

LGTM

jasnell pushed a commit that referenced this pull request Mar 15, 2016
`isIPv4` and `isIPv6` are implemented on top of `isIP`, which in turn
checks the sting for being both IPv4 and IPv6, which can be inefficient
in some scenarios. This commit makes them use `uv_inet_pton` directly
instead.

PR-URL: #5478
Reviewed-By: Evan Lucas <evanlucas@me.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Roman Reiss <me@silverwind.io>
@jasnell
Copy link
Member

jasnell commented Mar 15, 2016

Landed in 3b20941

@jasnell jasnell closed this Mar 15, 2016
evanlucas pushed a commit that referenced this pull request Mar 15, 2016
`isIPv4` and `isIPv6` are implemented on top of `isIP`, which in turn
checks the sting for being both IPv4 and IPv6, which can be inefficient
in some scenarios. This commit makes them use `uv_inet_pton` directly
instead.

PR-URL: #5478
Reviewed-By: Evan Lucas <evanlucas@me.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Roman Reiss <me@silverwind.io>
@evanlucas evanlucas mentioned this pull request Mar 15, 2016
rvagg pushed a commit that referenced this pull request Mar 16, 2016
`isIPv4` and `isIPv6` are implemented on top of `isIP`, which in turn
checks the sting for being both IPv4 and IPv6, which can be inefficient
in some scenarios. This commit makes them use `uv_inet_pton` directly
instead.

PR-URL: #5478
Reviewed-By: Evan Lucas <evanlucas@me.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Roman Reiss <me@silverwind.io>
MylesBorins pushed a commit that referenced this pull request Mar 30, 2016
`isIPv4` and `isIPv6` are implemented on top of `isIP`, which in turn
checks the sting for being both IPv4 and IPv6, which can be inefficient
in some scenarios. This commit makes them use `uv_inet_pton` directly
instead.

PR-URL: #5478
Reviewed-By: Evan Lucas <evanlucas@me.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Roman Reiss <me@silverwind.io>
MylesBorins pushed a commit that referenced this pull request Mar 30, 2016
`isIPv4` and `isIPv6` are implemented on top of `isIP`, which in turn
checks the sting for being both IPv4 and IPv6, which can be inefficient
in some scenarios. This commit makes them use `uv_inet_pton` directly
instead.

PR-URL: #5478
Reviewed-By: Evan Lucas <evanlucas@me.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Roman Reiss <me@silverwind.io>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
net Issues and PRs related to the net subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants