I made a perftest and it seems that for Chrome, Promise.resolve() is a lot faster than Object.observe():

http://jsperf.com/fastest-immediate-timeout

@jussi-kalliokoski you are creating a new object and calling Object.observe on every test run. If you do this once in the setup phase and just increment a property on each run, Object.observe is faster. Did you see the jsperf I linked to before? http://jsperf.com/setimmediate-test/17

@defunctzombie any thoughts on this?

@devongovett whoops, sorry! Completely missed the last paragraph. 👍 (Nice test case, btw!)

I am concerned that the size of this library keeps growing. It is better if
these are available as modules and libs use that instead of this next tick
global all the time. Modular is better for everyone.

On Monday, November 24, 2014, Jussi Kalliokoski notifications@github.com
wrote:

@devongovett https://github.com/devongovett whoops, sorry! Completely
missed the last paragraph. [image: 👍](Nice test case, btw!)

—
Reply to this email directly or view it on GitHub
#25 (comment)
.

Yeah but the problem is that the other core modules (e.g. streams) use process.nextTick. If we want streams etc. to be fast in workers, this is where the fix has to happen unfortunately.

@devongovett fair, ok will take a closer look over next few days

There is a bug in IE that causes message chanel (and post message and setInmediate see ) to be broken cujojs/when#197 you need to make sure IE never gets here and we never get here in the window.

Your perf issues are more likely due to the use of unshift in the queue not the latency of calling the async function as that is only needed the first time.

The perf issues are definitely not the queuing. As mentioned above, inside workers none of the existing async functions used are available so setTimeout is being used. In the jsperf comparing the techniques, the same queuing behavior is used for all of the tests, so that can't be the issue.

I meant the performance issue in the app, in the perf you are just measuring latency of the async providing method with a queue the actual async method is less relevent

I have merged another PR (62acf3e) which should help with perf and is a simpler fix. Please test out master with this merge and let me know if things are better. If they are, then I will release a version with these changes.

Yes, that is definitely a good fix. Seems similar in performance to me, for my usage.

Would be nice to at least use setImmediate instead of setTimeout when available though. That way we could polyfill setImmediate using some of these other techniques to get the best of both worlds. And when browsers implement setImmediate (IE already does), we'll get the performance benefit automatically. Seems like a minimal amount of code to do that.

sadly not so simple, the version in IE is broken cujojs/when#197 and certain things can prevent setImmediate (and MessageChannel and postMessage) from ever returning.

If you want low latency next tick I've written a dedicated module for that which handles all the ridiculous corner cases. Bear in mind the problem you are trying to solve is latency not performance, if you have multiple images being processed at the same time in the same worker then the latency will likely end up not being noticeable as the thread won't be wasting time when idle.