Possible scaling issue with QueueContainer<V>

[ricea]

If QueueContainer<V>.[queue_] is compiled to a JS array, then it's likely to become slow when the queue is very large.

See https://bugs.chromium.org/p/chromium/issues/detail?id=681493 for background information about when the same issue happened in Chrome.

[zenmumbler]

Hi @ricea, sorry I didn't notice this earlier, different GH account. I incorporated the test into the polyfill package (this repo is also now a monorepo) and tried it out. The issue is only present in Chrome; Safari and Firefox scale linearly with queue size. Nevertheless, it's a real issue and I'm not one to shy away from adding new containers to my code ;) I will add my Deque container (simplified to be just a queue) to the implementation soon and also incorporate the latest changes I saw in the streams commit updates.

Below are timings for the test on my 2010 iMac.

[zenmumbler]

By replacing the arrays with a basic queue the problem goes away in Chrome (same approach as you described in the linked issue). It's hard to really measure the effect of this change in Safari and Firefox as they spend a lot of time in internal promise code handling. Perhaps worth filing an issue with them.

Fun detail, Chrome using the SD polyfill is a bit faster than the internal implementation on this test. The timings vary, again due to the many, many promises, but every time SD comes out on top 😄