FR Doc: Explanation why speed is important; docs on replacing other parsers

[kkm000]

Hi Luke, I'm pretty naive in the node.js and all the surrounding infrastructure (I have been programming mostly in C++, Haskell, Ocaml, C#, F# and Bash during the last 20 years); my node.js experience is limited to building a single production typescript app, albeit not quite a helloworld—integrating GCB build with a BitBucket.org repo to run configurable matrix CI pipelines and drop artifacts on premises, so there is actually more than a single app). I certainly liked the language, especially with TS type support crutch. I am now looking for a solid high-level cli parser for my next project.

What seems missing from the documentation (which may possibly only seem due to my naivete) is the reason why it is important to parse command line quickly. Frankly, seeing the benchmarks I started to worry, after a negative experience with Python's slowness (the language has got a very apt name!); but node's V8 engine surprised me with its speed. I never thought of a CLI parser as a speed bottleneck.

My eyes are currently at the https://github.com/yargs/yargs CLI framework, although I'm going to eval a few. I admit I cannot put the benchmark in context, because it does not define what an "op" is; if you could explain it better (e.g., how many Kops/Mops does it take to parse an averagely complex exemplar Git or Docker command line on a random modern box), but the ×40 perf difference is indeed impressive! What is hard to grok is how it relates to the real world applications and absolute time. 100ms vs 4s is indeed a huge difference (4s is a show-stopper), 10ms vs 400ms is a nuisance to do away with, but 1ms vs 40ms is rather in the "who cares" range.

Also, it would be great if you added a bit of instructions on replacing the https://github.com/yargs/yargs-parser with your one in the yargs context, if that's doable.

Thank you! And, of course, all this probably doesn't make sense if that's a basic knowledge among node.js programmers; I'm certainly not one.