setImmediate via MessageChannel performance about setimmediate

[domenic]

Good call; I think the reason it looks as it does is only a historical accident. Feel free to submit a pull request :)

[wwalser]

I'll be flying for the next three days so I can't look into the performance of this in particular and actually Dom sent me something earlier this week that I haven't been able to look into yet either. You may be correct that this is what's causing the problem that I saw a few weeks ago in my own performance tests.

In brief my findings were that messageChannel would be faster than setTimeout 0 for the first three to five thousand iterations but then suddenly slow down to become the same speed. I suppose that problem could be a GC issue in which case your change would fix it. It could also be a generic MessageChannel performance problem.
https://gist.github.com/2718412
That page shows the basics of my performance tests, I've thought of some other approaches that I'd like to try out in a few days.

[Yaffle]

Chrome 21

with MessageChannel (before fix)
timeout: 1223
immediate: 4054
delta: 2831
percentage: 30.167735569807597

with MessageChannel (after fix)
timeout: 1221
immediate: 51915
delta: 50694
percentage: 2.351921409997111

with postMessage:
timeout: 1223
immediate: 60765
delta: 59542
percentage: 2.0126717682876656

with postMessage (with 3 additional listeners for "message" event):

window.addEventListener('message', function (event) {
if (event.data === 'test') {
console.log('test');
}
}, false);

timeout: 1222
immediate: 52358
delta: 51136
percentage: 2.333931777378815

[Yaffle]

seems,
delay with postMessage depends
on number of listeners for "message" event
window.addEventListener('message', ...)

so.... MessageChannel can be more preferable
(this is not fixed in my pull request)

[domenic]

Right, it's a good point. Hard to say which is best. Will have to think on it further, maybe gather more cross-browser data.