Hey @dieserikveelo, sorry for the late reply - haven’t had much time the last couple days.
Nice test. While I had my suspicions that Firefox’s console.log() method was causing the terrible performance in my last test (Test05), your test basically confirmed this was the case.
In the name of purity (and science!), I rewrote a new test to do effectively the same thing as Test05–that being, to send and receive a message each frame, recording the results:
Source:
Live (hosted):
http://project42.xyz/webworkerperftests/test06/
The difference is that this test no longer uses console.log() at all while it’s running the test, and it logs the results to a pair of pre-initialized arrays. After the test is done, it computes the results and dumps to console. While the code is an utter mess, I don’t think it’s possible to get the test itself any leaner as far as performance is concerned.
The setTimeout(fn, 0) hack is no longer needed, though I suspect it’ll still be useful in Firefox for times when the UI thread is busy.
Also, keep in mind this is still just two messages per frame. Next I’ll probably adapt Test04 (maximum message volume) to this format, and see how Firefox copes. Right now, Firefox edges out Chrome for me. I have a feeling Chrome will prevail in real-world scenarios, because in those the UI thread is almost always busy. We’ll see.
Using the polyfill in a browser without real workers would add more overhead to the UI thread than without the polyfill.
I’m not sure this would be the case. The engine is almost assuredly going to run on events anyways. Either way, I think we’ll probably arrive at a nice solution that handles both cases elegantly and in a manner that achieves the highest performance reasonably possible.
@trusktr re: IE10
As far as I’m concerned, IE10 can go see itself into the dumpster.