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

Nobody has claimed this yet.

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.

No file or test is named. Review the existing benchmark documentation and the yargs/yargs-parser context first; document why parsing speed matters with understandable operations and absolute-time examples, then explain how yargs users could replace yargs-parser with mri.

Written by the indexing model from the issue text.