4 ms·
There's serialization costs for going back and forth. In some contexts launching multiple workers is possible if you can split up work, in which case it would
by Touche 10y ago
There's serialization costs for going back and forth.
In some contexts launching multiple workers is possible if you can split up work, in which case it would be faster. Sorting a single array is not such a context though.
- laxd 10y agoMerge sort?
- SigmundA 10y agoThe demo doesn't seem to serialize anything, it doesn't transfer the array. I would guess the extra time is just worker initialization including fetching/parsing worker.js.
- cjdell 10y agoYou can bypass the serialisation cost by using the transferList for ArrayBuffer instances, which is used by typed arrays i.e. Int32Array, Float64Array etc. i.e. self.postMessage(myTypedArray, [myTypedArray.buffer]) I used this approach to generated geometry within a web worker for a WebGL project. Only downside is the web worker that initialised the array will lose ownership of the buffer and will have to create a new one to pass more information. https://developer.mozilla.org/en/docs/Web/API/Worker/postMessage https://developer.mozilla.org/en/docs/Web/API/Worker/postMes...
- Touche 10y agoYeah, it's really only useful for game dev and other math heavy use-cases. In normal JavaScript, which could also benefit from threads, you use Objects and Arrays, which can't be transferred.
- OskarS 10y agoYou can totally split sorting across different threads/cores, just divide the list up and do a final merge pass. Basically the idea behind external sorting, where the amount of data is not big enough to fit into main memory, so you have to sort chunk-by-chunk and then merge the chunks.
- BatFastard 10y ago3 more years and maybe HTML 5 will catch up to where Flash was 3 years ago! Here's to hoping!