
Demonstrating Web Worker: Sorting a 50K array in your browser - afshinmeh
http://afshinm.github.io/50k/
======
millstone
I don't know much about web workers. According to my understanding, they can
only communicate by message passing. This means that, if I have a 50K array
and wish to sort it via a web worker, I must copy it twice: once incoming and
again outgoing. This copying is likely to be as expensive as sorting it (well,
maybe not if you use bubble sort). How do you mitigate this?

~~~
Drakim
Fortunately, Transferable Objects (which didn't arrive until a bit after Web
Workers) solves this :)

[http://updates.html5rocks.com/2011/12/Transferable-
Objects-L...](http://updates.html5rocks.com/2011/12/Transferable-Objects-
Lightning-Fast)

~~~
amelius
If one wants to share data with two different web-workers (doing different
computations on the same immutable data), there is still a problem. Or so I
suppose (?)

~~~
Drakim
Yeah, you'd have to clone the data.

------
ColinWright
Deeply misleading title. It's basically pointing out that if you use "Web
Worker" then you can do stuff in the browser in background. It's really
nothing to do with sorting the array - it's just using that as a task for the
background work.

~~~
afshinmeh
Thank you. I just updated the title.

~~~
ColinWright
You need to update the title on this submission as well:

    
    
      Demonstrating Web Worker: Background
          sorting a 50K array in your browser
    

Or something similar.

~~~
afshinmeh
Cool, Updated.

~~~
ColinWright
I strongly recommend you update your web page title to say the same thing,
otherwise the mods here may adjust this title to match that one.

------
martin-adams
Web workers would have been a must have for a project I worked in a few years
ago. I had to write a real-time video allocation algorithm that had dynamic
hardware with extreme combination constraints, and varying encoding rules for
audio and video (think HD, SD, Dolby, stereo). It also had to allow for
changes without moving existing allocations (otherwise viewers TV programmes
would glitch).

The back-end was an embedded device that only accepted XML and could not do
the calculation.

I had to have this do the allocation in IE8! So I wrote a timer based
allocation routine that would release the UI thread enough to not lock up the
browser. It worked (sort of), but was ugly and took way too long!

------
jlarocco
I think it should be more clear that it's using bubble sort to purposely take
a longer time than necessary.

I'd expect sorting an array of 50k elements to be instantaneous on a modern
machine, even in Javascript.

My first thought was, "WTF? Sorting 50k elements is a big deal?"

~~~
qw
It seems that there are significant differences in browsers as well.

    
    
      Windows 8
      --------------------
      Firefox v38 | 2629ms
      Chrome v40  | 4281ms 
      IE v11      | 7899ms

------
jtchang
I found this thread from about 3 years ago interesting:

[https://news.ycombinator.com/item?id=2566365](https://news.ycombinator.com/item?id=2566365)

Basically if web workers could access the GPU as well via WebGL.

------
TheLoneWolfling
...with bubble sort.

Might want to mention that in the title.

------
meerita
I did all the tests faster without webworkers than with them.

~~~
onion2k
They're not faster. They take roughly the same amount of time, but with an
extra bit of overhead for instantiating the worker and an event to say it's
finished, so they're actually slower. But.. they don't block the browser doing
things so the page still responses to input while they're working. If you need
to do something that's doing to take 8s (e.g. this demo on my Mac Air), having
the user still able to interact with the page while a progress bar updates is
a _huge_ advantage.

~~~
eueueu
It's trivial to periodically pass control back to the UI with setTimeout or
setInterval.

So doing something that takes 8s doesn't have to block the UI at all. The
"without webworkers" version should be renamed to "Naively programmed version"
or something.

~~~
magicalist
It gets ugly fast. Most tasks are not a simple sort. There's a reason that
cooperative multitasking is not widely used in operating systems anymore.

~~~
eueueu
Javascript is not an operating system.

There aren't many operations in javascript which will block. The only real
issue is that your javascript code executes in the same thread as UI. Which
just means you need to think a bit harder about keeping it responsive.

"Start threads!" in programming is usually a lazy hack.

~~~
LnxPrgr3
Lazy hack, or using OS/browser/whatever features instead of reinventing them
poorly?

What's the benefit you get from programming like that?

~~~
eueueu
Because once you introduce threads, your program complexity increases
massively. You're now throwing a few groups of instructions at the CPU and
saying "Hay! Execute these instructions in any order you like". Then you're
adding code to deal with the issues of that random execution entails.

Also, it's not faster, so what's the actual point?

The browser should use all CPU cores efficiently to make javascript fast.
Exposing WebWorkers to javascript programmers IMHO is totally the wrong way to
do that.

------
moonbug
Is co-operative multitasking really as far as it's got, after two decades of
web progress? Sheesh.

~~~
tantalor
Mozilla is working on SharedArrayBuffer
([https://blog.mozilla.org/javascript/2015/02/26/the-path-
to-p...](https://blog.mozilla.org/javascript/2015/02/26/the-path-to-parallel-
javascript/)) which brings something like pthreads to the browser.

