Refactor test-readline-async-iterators into a benchmark

[mcollina]

          test-readline-async-iterators is now flaky in the CI: https://github.com/nodejs/reliability/issues/640, and it's quite slow to run so it might create timeout issues on slower machines in the CI. is there a reason the performance test must be done in the test suite? It looks like this could be placed in benchmarks instead

Originally posted by @joyeecheung in #41276 (comment)

[shubham9411]

Hi @mcollina, I was thinking to pick this issue.

According to my current analysis test-readline-async-iterators is taking time in CI because of added testPerformance. In my local with testPerformance test is taking around 5s while without that it is taking around 0.05s. We want to move that perf test to benchmark. Is my understanding correct? Thanks

[joyeecheung]

My suggestion would be, simply moving

node/test/parallel/test-readline-async-iterators.js

Line 153 in 64a5c01

for await (const line of oldWay.call(rlOldWay)) {

and the implementation of oldWay to benchmark/readline/readline-iterable.js, and add a type: ['new', 'old'] to the benchmark configs that allows the benchmark to run it with both the new and the old way of async iteration - it already runs the new way of async iteration and just needs a new config for the old way. If anyone still wants to compare the numbers they can just run the benchmarks once and compare the op/s output of different configs. We have been doing that for benchmarking different URL parsers for example. (Not sure how I can make myself clear without writing the whole thing myself, but you can read up on https://github.com/nodejs/node/blob/main/doc/contributing/writing-and-running-benchmarks.md#basics-of-a-benchmark to understand how benchmark works).

[shubham9411]

@joyeecheung I've opened a PR with your suggested changes. Can you please take a look. :)

[Prateek462003]

Hey @shubham9411 are u still working on this Issue?

[shubham9411]

Yup @Prateek462003, Here is link to the PR #49237.