Html Web Worker Woes - Data Analysis not an Option
by Guido Tapia
February 18, 2010
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?
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|