I’ve slightly altered the test to lower the verbosity and measure the roundtrip instead. I’m getting the following numbers (Firefox outperforming Chrome!):
Chrome (Mac 45.0.2454.85): 0.21ms
Firefox (Mac 39.0.3): 0.17ms
Note: this is a roundtrip from UI --> Worker --> UI
index.js:
var t = performance.now(),
samples = 60,
i = 0,
n = 0;
console.log('UI load timestamp: ' + t);
var worker1 = new Worker('worker.js');
worker1.onmessage = function (e) {
i++;
// Receive and log.
t = performance.now();
if (i % samples === 0) {
console.log('UI --> Worker --> UI: ', (t - e.data.ui), '~', n / samples);
n = 0;
} else {
n += (t - e.data.ui);
}
};
var rafLoop = function () {
//Send a message, and receive a reply (once per-frame).
setTimeout(function () {
var t = performance.now();
worker1.postMessage({ui: t});
}, 0);
window.requestAnimationFrame(rafLoop);
};
rafLoop();
worker.js:
onmessage = function(e) {
//Receive and log.
var t = performance.now();
e.data.worker = t;
postMessage(e.data);
t = null;
}
update:
Using a hacked-together polyfill worker class in the main UI thread gives me the following roundtrip data:
Note: this is without actual workers, just a fake polyfill one.
chrome: 0.013ms
firefox: 0.002ms
making the overhead roughly 0.2ms and 0.17ms
Firefox however will drop to 0.0005ms after a period of 15 seconds… which feels really weird to me. The other way around would make more sense probably.
Next test: doing some actual work inside the workers to see how that influences the behaviours.
update 2:
Adding heavy computation inside the workers just adds to the overall overhead, as expected.
One thing that I took out of this test is that it’s fairly easy to create a polyfill Worker, allowing the user to maybe determine whether to use real workers, or route everything through the polyfill worker for ‘normal’ behaviour.
