After careful reading of the specs I thought this would be great but after some initial tinkering I found that communications between threads was
done through the postMessage feature supported by modern browsers.
This instantly raised some suspicions as I know that this is a text only feature, I know FF will auto serialize/deserialize to/from JSON but this as
expected performs pretty poorly for large data sets. But I gave it a benefit of the doubt thinking that there was no way that someone would go to
the extreme pains of implementing a threading framework and cripple it by not allow memory references to be passed between threads.
WRONG!!! And now I can say that the new threading features in browsers is only usefull for making the UI more responsive. Now don’t get me wrong
thats great and a huge relief not to be having to use setTimeout hacks everywhere but seriously?? Why would you break my heart like that?
Threading is critical in calculation intensive or data analysis intensive applications. The PicNet Mouse Eye Tracking service
a huge amount of calculations that lock the browser JS thread but it is impossible for me to use web workers. Why is that?
The cost of postMessage
postMessage can transfer strings between threads. But it is very rare that data requiring analysis is solely string based, mostly we are working with other primative types as well such as
numbers, booleans, DateTimes, etc. And the cost of converting (serializing) strings to/from these data types is huge. After some early prototypes I tossed the idea
of using Web Workers aside. I know this is very early days in the life of Web Workers but I was quite taken aback by this crippling flaw in the specs.
Lets look at numbers
K, lets support my whinging with numbers. Below is a table that shows an expensive operation on an array of numbers. We process the array using the specified number of threads. Note:
Refresh to see it running in real time:
|1 Threads||2 Threads||3 Threads||4 Threads||5 Threads|