Hi Bert!

> What's the overhead of the WebWorkers? I mean compared to just running
> the JS code from SqueakJS:
>
> JS at: 'fib' put: (JS Function new: 'n' with: 'return n <= 1 ? n :
> fib(n-1) + fib(n-2)').
> JS fib: 38
> ==> 39088169

     On my 2017 MBP 13', it costs 40ms to create and start a Web Worker,
and 1ms for each communication between it and the thread that created it
(for posting input data and results).

     The overhead of running the JS code with the JS bridge directly is
lower (sub-millisecond), but you commandeer the main JS thread that's
running the SqueakJS VM while that JS code runs. By using a worker, the
SqueakJS UI continues uninterrupted while the JS code runs in a separate
thread, potentially on a separate physical processor. That's what I
meant by Web Workers being "convenient". :)  I have better examples
coming up where parallelism is actually relevant to the use case, and
not just the convenience of running the benchmark.

     There are also optimizations that the JS engines of various web
browsers employ when code is running in a worker, largely isolated from
the environment of the main JS thread (especially when the worker is
invoked many times instead of just once).


-C

--
Craig Latta
Black Page Digital
Amsterdam :: San Francisco
craig at blackpagedigital.com
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)