JavaScript Performance

Resources

The Importantance of Performance

Our applications keep getting bigger and bigger and bigger. That being said, download speeds have also declined alongside unlimited plans!

Perception times

Wetware perception-reaction times:

Aims:

The Importance of Measuring

Rules to optimisation:

The rough outline:

The Cost of JavaScript

The size of the JS we are sending is growing at an incredible rate. Sometimes, parsing and compiling is the real culprit. Steve shows an example of an application loading and with the time being "scripting".

Chrome also gives you little "red triangles" to help give you information on places you are causing issues.

The steps of JS

There is also an "optimizing compiler" that taks some code from the interpreter and spits out optimized machine code. Sometimes if it can't be optimized, it goes back to the byte code output from step 5.

The link to the slide diagram is here.

Parsing

Parsing is slow, can be 1MB/s on mobile. The aim is to do as much parsing as you need and as little as you can get away with.

There are two phases:

Generally lazy is a good thing.

Here is an issue we can run into:

// Eager parse
const a = 1;
const b = 2;

// Take note of function here, but we'll parse the body when we need it
function add(a, b) {
  return a + b;
}

add(a, b); // Whoa, go back and parse
copy

ASTs

With the AST, we have everything that we need to make our byte code.

The Optimizing Compiler

Three things that the engine does to help you out:

V8 also has flags to show us what is coming to our optimised comppiler.

node --trace-opt js-file.js
copy

The above code when run will show what is marked for optimized recompilation. If you run node --trace-opt js-file.js | grep add you can get even less noise.

Deoptimization, Deleting Properties

Running node --trace-opt --trace-deopt js-file.js | grep add will show us both the optimisations and deoptimisations!

The follow coding shows the deoptimisation:

const add = (x, y) => x + y;

performance.mark('start');

while (iterations--) {
  add(a, b);
}

add('foo', 'bar'); // this line creates a deoptimisation!

performance.mark('end');
performance.measure('My special benchmark', 'start', 'end');
copy

The issue in the above is that different types of arguments causes an issue for the optimiser.

To debug a little further, we can use the following to avoid optimisations:

const add = (x, y) => x + y;

performance.mark('start');

%NeverOptimizeFunction(add); // only for Node

while (iterations--) {
  add(a, b);
}

add('foo', 'bar'); // this line creates a deoptimisation!

performance.mark('end');
performance.measure('My special benchmark', 'start', 'end');
copy

Then we can run node --allow-natives-syntax benchmark.js, which we will see causes a serious deoptimisation.

Other syntax we can use:

%OptimizeFunctionOnNextCall(add);
copy

How does it work?

Once we had a function that started taking a different type, it de-optimizers. It will only try optimizing a couple of times before it just stops with this.

The next example was with a class:

class Point {
  constructor(x, y) {
    this.x = x;
    this.y = y;
  }
}

while (iterations--) {
  const point = new Point(2, 4);
  delete point.x; // this cause a de-op - why?

  JSON.stringify(point);
}
copy

We notice that if we delete one of the properties (not the last) will cause a de-optimisation!

The example is then used with objects with different properties. So why would one be faster than the other?

Because there is a type system in v8! Crazy.

It is to do with the morphism of an object!

Optimizing Objects

Another v8 hidden native tool we can use is %HaveSameMap() with --allow-natives-syntax.

const a = { a: 1 }
const b = { b: 1 }

console.log(%HaveSameMap(a,b)) // false - makes sense

const a = { a: 1 }
const b = { a: 1 }

console.log(%HaveSameMap(a,b)) // true - makes sense

const a = { a: 1 }
const b = { a: 50000000000000 }

console.log(%HaveSameMap(a,b)) // false - 32bit int is a diff type

const a = { a: 1 }
const b = { a: 5 }

console.log(%HaveSameMap(a,b)) // true - same int type

const a = { a: 1 }
const b = { a: 5, x: 2 }

console.log(%HaveSameMap(a,b)) // false

const a = { a: 1, x: 1 }
const b = { a: 5, x: 2 }

console.log(%HaveSameMap(a,b)) // true

const a = { a: 1 }
const b = { a: 5, x: 2 }

a.x = 3

console.log(%HaveSameMap(a,b)) // false - interesting!

const a = { a: 1 }
const b = { a: 5 }

a.x = 3
b.x: 2

console.log(%HaveSameMap(a,b)) // true

const a = { a: 1 }
const b = Object.assign({}, a)

console.log(%HaveSameMap(a,b)) // false - also interesting!

const a = { a: 1 }
const b = Object.assign({}, a)
const c = Object.assign({}, a)

console.log(%HaveSameMap(c,b)) // true

class Point {
  constructor(x, y) {
    this.x = x;
    this.y = y;
  }
}

const a = new Point(1,2)
const b = new Point(5,12)

console.log(%HaveSameMap(a,b)) // true
copy

So what's happening? Dynamic lookup.

V8 keeps a secret type system behind your back. It tries to do less work where possible (in a conservative way).

As it does this, the order that the properties got added to the object matter!

// for examples sake, we'll declare the class names cached
const obj = { x: 1 }; // c0
obj.y = 2; // now c1
const another = { x: 1, y: 23 }; // c2 - path matters!
delete another.y; // c3
copy

Scoping and Prototypes

Scoping can hae dramatic implications on the performance of our code.

In this example, he creates a class from within a function and there is a dramatic change (9ms to 800ms).

When having a class within the scope of another functionn, they also don't share the same map. The problem is that the class is now pointing to a different prototype chain.

The takeaways:

Function Inlining

const square = x => x * x;
const sumOfSquares = (a, b) => square(a) + square(b);
copy

Why are these speeds optimised? It's thanks to inlining.

We can see this in action using the --trace-turbo-inlining Node flag.

When a function is inline, it just rewrites what happened the first time to happen to second time to stop yourself from calling the function again.

How Web Pages Are Built

The render tree has:

This is done using style calculation.

Note: the more complicated the selectors, the longer the calculation takes.

Takeaways:

JavaScript and the Render Pipeline

JS can change the following (not a complete list):

All of these will cause the render flow to start again from the layout stage.

Layouts and Reflows

Layout is used for the first time, reflow is for following times.

Each browser has different ways to optimise this.

About reflows:

Note: There is a lot that causes a reflow. Requires a repaint and is also expensive.

How to avoid reflows

The exercise links to a CodePen to check the impact of reflows.

Layout Thrashing

Also known as forced synchronus layout.

Chrome will also help us a bit with the red flags where it thinks we are doing a forced reflow.

Takeaways:

// using requestAnimationFrame
elements.forEach((element, index) => {
  const top = element.offsetTop;
  const nextPosition = value; // value is stubbed for something more complex
  requestAnimationFrame(() => {
    element.style.transform = `translateX(${nextPosition}px)`;
  });
});
copy

FastDOM

FastDOM is used to prevent layout thrashing. There are only two methods you care about: measure and mutate (aka read and write).

It is used for scheduling.

// using fastDOM
elements.forEach((element, index) => {
  fastdom.measure(() => {
    const top = element.offsetTop;
    const nextPosition = value; // value is stubbed for something more complex
    fastdom.mutate(() => {
      element.style.transform = `translateX(${nextPosition}px)`;
    });
  });
});
copy

Frameworks and Layout Thrashing

Frameworks will attempt to help you prevent layout thrashing.

React does a lot of things under the hood to help you. When using React in dev mode, it is worth to note that the performance measuring will take a hit.

Painting

The rule: use your tools to see if you're painting.

From the extra rendering tools, we can use Paint flashing to help you know when you're painting again.

The Compositor Thread

Some of our nice threads:

Things the compositor thread is good at:

Note: Layers are an optimization that the browser does for you under the hood. So what gets one?

will-change property

This property can help the browser decide to make things its own layer.

.sidebar {
  will-change: transform; // makes the recommendation
}
copy

We can use the layers property in Chrome to check this out.

Note: DO NOT make everything a layer. The browser is already trying to help you under the hood.

If there is something that happens temporarily, you can use this property in JavaScript and then remove it after, ie:

element.addEventListener('mouseenter', () => {
  element.style.willChange = 'transform';
});

element.addEventListener('animationEnd', () => {
  element.style.willChange = 'auto';
});

element.addEventListener('mouseleave', () => {
  element.style.willChange = 'auto';
});
copy

Latency and Bandwidth

Bandwidth vs latency:

TCP focuses on reliability

An example shown is sendping. The tip is to put things everywhere using a CDN.

Cache

This section goes over how to store data, what happens when things go stale and how to cache-bust.

Cache-busting ways:

Service Worker

Instead of asking the Internet directly for things, the service worker becomes the middle man. It also means you can work offline depending on what is kept in the cache.

There is another course on this to dive deeper.

Lazy Loading

Lazy-loading and pre-loading. Use this wherever possible as people needs things.

We can use tools like webpack-bundle-analyzer. It is a great way to visualise where all the code is.

In the example, Steve shows how to reduce Lodash first. This is first done by ES6 module imports to help the analyzer tree shake.

React Loadable

The demo here has short demo of showing lazy loading with a React component.

HTTP/2

The increasing support comes with unique characteristics.

What's wrong with HTTP/1.1?

Build Tools

Paying the Babel tax

Note that converting from futuristic code from Babel to supported code can actually end up turning into a lot of code and be costly.

An example of something expensive is async/await!

Useful Babel plugins

Prepack

Prepack aims to make JS run faster. Examples shown were pre-emptively changes things like fibonacci calls to make things faster.

Note: Prepack is not production ready.

Things not covered