Web Worker Test

For background and discussion, see my Blog Post.

Web Workers is a technology that allows multiple threads in WebBrowsers and JavaScript. This little page/application makes some performance tests.

JavaScript in the web browser is single threaded. So when your program is busy computing something the GUI will not update and not respond to user input. This will create a bad user experience.

Try click Dry Run below. For 5 seconds it should print X to 5 lines. If the computer/browser is busy it will miss an X or two, writing (later) a . instead. Since we don't do anything else it should print Xs nicely, missing very few.

The other buttons (except Reset) do the same standardised job for 5 seconds. During the 5 seconds it will also try to print X. However, when the job is blocking (too demanding) it will fail to print X. You can think of this as the frame rate or refresh rate going down.

Try click Timeout 0ms, 50ms loops. You should get 1-2 (perhaps more) missed updates between each X. What happens is that the job works for 50ms and then calls window.setTimeout to call itself again in 0 ms. This gives the GUI time to update: necessary for the GUI experience, bet less work is getting done. So this is all about a tradeoff between GUI responsiveness and work actually getting done (which in the end is done for the user, also affecting the experience).

A few words on the job itself, very simple: 1) Create an array of random numbers, 2) Sort the array, 3) Get the median. The cnt value indicates how many times the 1-2-3 job is done. What we are looking for is many X and a high cnt value.

The tight loop locks the GUI for 5 seconds. It should produce the highest cnt value (except for 2 workers) but the worst experience.

The other two timeout options do one loop at a time or loops for 50ms each time, before UI can update.

Now to the Workers. The first workers (not saying sort) do all the job 1-2-3. So it is a very cheap job to start (not much data is sent to the worker). The 1 Tight Loop worker works for 5 seconds and then returns the result. The 50ms worker works for 50ms and then returns its result so far. But the GUI is not (should not be) disturbed because the worker lives in its own thread. The 1 by 1 workers just do 1-2-3 a single time so you can say they require more attention. Queue means that two jobs are immediately sent to the worker, and as soon as one is returned a new one starts, and the worker should always have something to do. 2 Workers is what it seams, and if your CPU has multiple cores 2 workers should be faster than 1.

Finally the last sort options: The main program produces the random array (step 1) and sends it to the worker to sort it (step 2). The worker sends back the sorted array to the main program that finally gets the median. The problem here is that much more data is sent (copied) from main program to worker, and there is a risk more time is spent copying data than actually getting anything useful done (job OR updating GUI).

Now try for yourself. The results seem to vary quite much between different browsers. And also if the browser is not in focus or even hidden.

This GIF should always animate (origin)

{{ wwt.timer() }}s

Medians: min={{ wwt.median.min.toFixed(2) }} max={{ wwt.median.max.toFixed(2) }} cnt={{ wwt.median.cnt }}

{{ t }}