Performance of for await of (async iteration)

I hope this is the right place to ask the question and that this hasn't already been discussed to death elsewhere. Feel free to direct me elsewhere or close the issue if I've missed something. In short, I am one of the maintainers of exceljs (which is basically a transfrom stream taking in a read stream, unzipping its contents, running an xml parser on the unzipped chunks and then emitting back excel-related events) and we're in the process of adding support for async iteration via for await of (https://github.com/exceljs/exceljs/pull/1135). In doing that, we've noticed that for await of is significantly slower than the current `.on('data',..)` based approach. Our benchmark is not a microbenchmark, but a full end-to-end benchmark incl. creating and analyzing excel objects in memory (https://github.com/exceljs/exceljs/pull/1139). Switching to for await of (vs. handling the events in sync callbacks) decreased performance by around 60%. I have debugged this issue (https://github.com/lddubeau/saxes/issues/32) and in short, the issue arises because for every chunk/event passed into our transform stream, we emit out a magnitude greater of chunks/events. And so what's causing the performance is that the callback code would run through these emitted chunks/events mostly synchronously, whereas the current implementation of `Symbol.asyncIterator` on `Readable` calls `setImmediate` between each event, which is quite expensive. I wrote a simple microbenchmark to compare for of against for await of on the same array or iterator, and the difference is around 10x. So we've come up with this 'hack' where instead of emitting one-by-one all of these chunks/events that our transform produces, we now gather them up in an array and emit that once. Or phrased another way, instead of calling `this.push()` for every excel related event that we produce, we call, for each chunk written into our stream, a lot of `this.events.push()` (where `this.events` is just an array that initialized in th…