Conversation
b34df4d to
33759f2
Compare
benchmark/dns/lookup.js
Outdated
There was a problem hiding this comment.
Does it make sense to throw in localhost so that there's a hostname lookup since that probably takes a different path through the code?
There was a problem hiding this comment.
I chose this list because they don't actually hit libuv and so (in this particular case) it is a better measure of the forced async callback change. Also when you start passing in non-empty hostnames, the n value will need to be lowered quite a bit.
lib/dns.js
Outdated
There was a problem hiding this comment.
any reason to not use net.isIPv4 here?
There was a problem hiding this comment.
Faster to not have to call into C++ land IIRC, especially since we only need to check at most a few characters anyway.
There was a problem hiding this comment.
@mscdex how much faster is this compared to something simpler like
function digits(code) {
return code >= 48 && code <= 57;
}|
/cc @nodejs/collaborators |
0.0.0.0 is more common than other special ipv4 addresses, so it is possible that we may not get ENOTFOUND for such addresses. Instead, this commit uses a less common address that is reserved for documentation (RFC) use only. PR-URL: nodejs#13261 Reviewed-By: Roman Reiss <me@silverwind.io> Reviewed-By: James M Snell <jasnell@gmail.com>
It appears that either c-ares no longer calls callbacks synchronously or we have since explicitly taken care of the scenarios in which c-ares would call callbacks synchronously (e.g. resolving an IP address or an empty hostname). Therefore we no longer need to have machinery in place to handle possible synchronous callback invocation. This improves performance significantly. PR-URL: nodejs#13261 Reviewed-By: Roman Reiss <me@silverwind.io> Reviewed-By: James M Snell <jasnell@gmail.com>
PR-URL: nodejs#13261 Reviewed-By: Roman Reiss <me@silverwind.io> Reviewed-By: James M Snell <jasnell@gmail.com>
33759f2 to
3c989de
Compare
0.0.0.0 is more common than other special ipv4 addresses, so it is possible that we may not get ENOTFOUND for such addresses. Instead, this commit uses a less common address that is reserved for documentation (RFC) use only. PR-URL: #13261 Reviewed-By: Roman Reiss <me@silverwind.io> Reviewed-By: James M Snell <jasnell@gmail.com>
It appears that either c-ares no longer calls callbacks synchronously or we have since explicitly taken care of the scenarios in which c-ares would call callbacks synchronously (e.g. resolving an IP address or an empty hostname). Therefore we no longer need to have machinery in place to handle possible synchronous callback invocation. This improves performance significantly. PR-URL: #13261 Reviewed-By: Roman Reiss <me@silverwind.io> Reviewed-By: James M Snell <jasnell@gmail.com>
PR-URL: #13261 Reviewed-By: Roman Reiss <me@silverwind.io> Reviewed-By: James M Snell <jasnell@gmail.com>
|
should this land in LTS? If so it will need to bake a bit longer. Please change labels as appropriate |
Example results with the included benchmark file:
I looked at the original commit where the "forced" async callback mechanism was added and I was not able to reproduce the sync callback issue with the tests included with that commit. My guess is that either c-ares changed or we have since manually taken care of such possible sync situations (e.g. empty hostnames or looking up an IP address).
I've also ran the dns tests in test/internet and there are no problems there either.
CI: https://ci.nodejs.org/job/node-test-pull-request/8343/
Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passesAffected core subsystem(s)