process.nextTick is slow

[jimmywarting]

setTimeout is clamped down to 4ms and even more when tab is hidden.
I saw some old PR attempt at using Observer PostMessage immidate and other but you still use setTimeout and that came back and bite us when transferring data webtorrent/webtorrent#1568

Could you look into using something faster then setTimeout?

[calvinmetcalf]

hey so I replied in the other issue but the gist is that there are some reasons for not putting that fancy fast things in this default library but i have a different library that it might make sense to use.

[tinchoz49]

What about try to use queueMicrotask and use the old one behavior as a fallback?

[tinchoz49]

Or if we use https://github.com/calvinmetcalf/immediate we can add support for window.queueMicrotask there :)

[calvinmetcalf]

the latter is probably a better option, this library get's included in a lot of bundles so the aim is to keep is small

[tinchoz49]

It's true is everywhere 😄 and I understand your point but if you don't mind I'm going to do a PR with the changes that I was thinking and you can tell me if it's too much.

[alecgibson]

We've just run into this. It's particularly bad if your test suite relies on nextTick() a lot in a browser environment.

I've tried monkey-patching with the proposed MessageChannel fix I've seen about, and it seems to work well with good compatibility (even back to IE10!). Is there any appetite to move in that direction? I'm happy to put together a pull request, if so?