search

defunctzombie / node-process

process information for node.js and browsers
MIT License
122 stars 62 forks source link

process.nextTick is slow #86

Open jimmywarting opened 5 years ago

jimmywarting commented 5 years ago

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 https://github.com/webtorrent/webtorrent/issues/1568

Could you look into using something faster then setTimeout?

calvinmetcalf commented 5 years ago

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 commented 4 years ago

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

tinchoz49 commented 4 years ago

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

calvinmetcalf commented 4 years ago

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 commented 4 years ago

It's true is everywhere :smile: 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 commented 5 months ago

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?