Parallelism

& javascript

By. Saad Abbasi

wHO AM I?

Details:

Skills:

🏃🏻‍♂️

🎮

I ❤️

Good News

bad News

 1 

 1 

LESS CODE

MORE THEORY

👍

Mind Changing

not platform specific

Might change the way you write Web Apps

👍

back to the start

⃔

⃔

Event Queue

Call Stack

 Event Loop

concurrent

Async Tasks

💻

Events

What the heck is the event loop anyway? | Philip Roberts | JSConf EU

So, the problem is

  • Sync operations can lock the UI thread
  • Sync operation can not be parallelised 
  • Sync operations can cause animation/transition lags
  • Continuous background operations cause heavy UX
  • Web has Sync APIs like LocalStorage
  • Keeping up with frame budgets (16.66ms on high end devices, lower on older ones)

-Jake Archibald's - Into the loop (JS Conf 2018)

But, Good News is

Its not just javascript problem

But rather it boils down to concurrency and parallelism

Parallelism is about doing multiple things at once, while concurrency is about dealing with multiple things at once 

- Rob Pike

Other Thread

Main Thread

typical methodology to handle long running sync operations

🎊 WEB HAS SOLUTION 🎊

AND MORE to offer

web

workers

/ ** Main Thread */

const worker = 
    new Worker('@scripts/worker.js');






worker.postMessage('Hey Kid');



worker.onmessage = (ev) => {
    const msg = ev.data //'Hello Man'
    console.log(msg);
};



worker.terminate();
/ ** Separate Execution Env */

importScript('./scripts/fns');

// Methods/Objects/etc inside 'fns' 
// - will be globally available




self.onmessage = e => {
  const message = e.data;
  console.log(message); // 'Hey Kid'




  postMessage("Hello Man");
};


self.onclose = () => {
// Unsubscribe all the listeners
// Do needful before termination
}

Workers & types

Workers

Web Workers

Service Workers

Animation Workerlets

Dedicated 

Shared

...

Inside a web worker

Almost everything, but few limitations

  • No direct DOM access (not even needed)
  • No image loading or caching
  • No access to Geolocation and Localstorage
  • No ES6 import statements
  • No canvas or SVG creation
  • postMessage channel does serialisation and deserialisation
  • ... possibly more

web worker In a nutshell

Main/UI Thread

Dedicated

worker

Keeps UI 60 FPS

Sync/ FPS Dropping Ops

(post)Message Channel

Main Thread

DW-3

DW-1

SW-1

Workers In action

Polling data Mappings & Transform

Maths & Statistics

Shared Operations

DW-MC

SW-MC

the goal is

  • Putting load off the main thread
  • Distributing operations among less possible workers
  • Make operations sequence independent or parallel
  • Optimising communication and operation times
  • Making app smooth and responsive, yet memory optimised

benchmarks

  • Instantiation time = 8-10ms
  • Initial message round trip = ~40ms
  • Communication latency (message channel) = ~ 0.5ms
  • Max message size = ~1300kb
  • Communication speed (message channel) = ~80kb/ms

Timestamps may vary on different browsers

performance tips

  • Keep message size small as possible
  • Try to keep less hops in message channels
  • Stringify your post messages (fully, not partially)
  • Use transferable objects where possible
  • Make expensive network calls in workers
  • Unsubscribe listeners on component unmount
  • Parallelise but not everything

CAN i use?

WEb workers with 96.1%

Shared workers with 41.1%

currently experimental

WORKER Threads landed in Node v10.5.0

But sooner they will be ready to use in Production.
So, its very right time to learn it.

Thats pretty much it

{github, linkedin, *}/isaadabbasi

get connected

WebWorkers

By Saad Abbasi

Made with Slides.com

WebWorkers

Thinking beyond single thread. Execute JavaScript in parallel.

  • 316

More from Saad Abbasi