dns: fix issues in dns benchmark

[ian-perkins]

The benchmark script for dns contained functions with args declared
but never used. This fix removes those arguments from the function
signatures.

No test existed for the dns benchmark so one was added to the
parallel suite.

The dns benchmark uses the core dns.lookup() function which does not
access the network but instead uses "an operating system facility
that can associate names with addresses, and vice versa" e.g. similar
to ping; however, it is a synchronous call which runs on the libuv
threadpool - the number of test calls was therefore reduced to 5e4
(from 5e6).

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• commit message follows commit guidelines

Affected core subsystem(s)

[Trott]

We just want to make sure the thing runs so I think this could be n=1.

[refack]

Could you also add:

'--set','all=false','--set','name=127.0.0.1',

so as to minimize the breadth of the benchmark even further.

[Trott]

The most important fix is that this changes the script from one that doesn't work to one that can actually run. :-D

[Trott]

Before this commit:

$ ./node benchmark/run.js dnsdns/lookup.js/Users/trott/io.js/benchmark/common.js:80 throw new TypeError(`configuration "${key}" had type ${typeof value}`); ^TypeError: configuration "all" had type boolean at recursive (/Users/trott/io.js/benchmark/common.js:80:15) at recursive (/Users/trott/io.js/benchmark/common.js:91:9) at Benchmark._queue (/Users/trott/io.js/benchmark/common.js:99:5) at new Benchmark (/Users/trott/io.js/benchmark/common.js:18:21) at Object.exports.createBenchmark (/Users/trott/io.js/benchmark/common.js:7:10) at Object.<anonymous> (/Users/trott/io.js/benchmark/dns/lookup.js:6:22) at Module._compile (module.js:573:30) at Object.Module._extensions..js (module.js:584:10) at Module.load (module.js:507:32) at tryModuleLoad (module.js:470:12)
$

After this commit, it actually runs.

[Trott]

And after:

$ ./node benchmark/run.js dnsdns/lookup.jsdns/lookup.js n=5000000 all="true" name="": 4,485,516.774544048dns/lookup.js n=5000000 all="false" name="": 4,614,725.86397749dns/lookup.js n=5000000 all="true" name="127.0.0.1": 2,519,219.886801595dns/lookup.js n=5000000 all="false" name="127.0.0.1": 2,523,608.1753037865dns/lookup.js n=5000000 all="true" name="::1": 2,633,747.082621402dns/lookup.js n=5000000 all="false" name="::1": 2,705,813.055286177
$

🎉 Thanks, @ian-perkins!

[Trott]

LGTM. Welcome @ian-perkins and thanks.

[Trott]

Tiny nit: The subsystem here should likely be benchmark rather than dns. If you don't mind changing it in the commit message, you'll save whoever lands this a few keystrokes.

[Trott]

CI: https://ci.nodejs.org/job/node-test-pull-request/9747/

[BridgeAR]

This actually breaks the intention of the Boolean. The value will be coerced to a Boolean again in line 15 and !!'false' === true. So you might just change this to [1, 0] instead.

[Trott]

@BridgeAR Oh, good catch.

[Trott]

Another possibility is to leave them as strings but change the assignment to something like: const all = conf.all === 'true' ? true : false;

To me, this has the advantage of being more readable and also seems to be at least a little bit in line with what some other benchmarks do. Of course, @BridgeAR's suggestion works too if that seems preferable.

[Trott]

Need to address the !!'false' === true thing noted by @BridgeAR. LGTM otherwise.

[refack]

LGTM % strings && 5e4 comments addressed

[BridgeAR]

@ian-perkins thanks a lot for following up on the comments. I must ask you to rebase though as described here as we can otherwise not cleanly apply your changes. Keep up the good work!

Looks like requests have been addressed, clearing my request for changes.

[Trott]

@BridgeAR Looks like this has no conflicts with master anymore. PTAL.

[jasnell]

hmm..looks like the conflicts were resolved by merging and not rebasing.

[Trott]

hmm..looks like the conflicts were resolved by merging and not rebasing.

Ah! Yes, extra commits, now I see. Yeah, ignore me, and @ian-perkins please rebase when you get a chance. :-D

[ian-perkins]

I'll try to do this today but can I first check what the rebase should do? Is it to squash all the commits I made into one? I read the referred doc and it mentions commits being squashed on landing so I suspect that I need to do something different in this case? Sorry for the basic nature of my questions...

[Trott]

@ian-perkins The rebase is to synch up your branch with the master branch on the upstream repository, and then re-apply your changes on top of that. (Hope that answers your question, but if not, feel free to ask clarifying questions here or hop on IRC to see if someone can help you!)

[ian-perkins]

I did the rebase and pushed to my fork - hopefully it's ok...

[Trott]

@BridgeAR PTAL

[BridgeAR]

LGTM

[Trott]

CI: https://ci.nodejs.org/job/node-test-pull-request/9826/

[BridgeAR]

Landed in 15ac1ea

@ian-perkins congratulations on your first contribution! 🎉